I just added a gif to a question, and on 2 different browsers, the gif stops after 2 cycles. When I have done this previously, the gif just keeps cycling round (as desired). Is this a new stack exchange thing, or is something going on my end?
A quick Google search produced this handy run-down of the GIF file format, which includes this section on looping:
Example (not in sample file): 21 FF 0B 4E 45 54 53 43 41 50 45 32 2E 30 03 01 05 00 00
The GIF89 specification allows for application-specific information to be embedded in the GIF file itself. This capability is not much used. About the only known public one is the Netscape 2.0 extension (described below) which is used to loop an animated GIF file. We'll go into more detail on looping in when we talk about animation.
The Netscape 2.0 looping block must appear immediately after the global color table of the logical screen descriptor. It is 19 bytes long.
byte 1 : 33 (hex 0x21) GIF Extension code byte 2 : 255 (hex 0xFF) Application Extension Label byte 3 : 11 (hex 0x0B) Length of Application Block (eleven bytes of data to follow) bytes 4 to 11 : "NETSCAPE" bytes 12 to 14 : "2.0" byte 15 : 3 (hex 0x03) Length of Data Sub-Block (three bytes of data to follow) byte 16 : 1 (hex 0x01) bytes 17 to 18 : 0 to 65535, an unsigned integer in little-endian byte format. This specifies the number of times the loop should be executed. byte 19 : 0 (hex 0x00) a Data Sub-Block Terminator.
As with all extensions, we start with 21 which is the extension introducer. Next is the extension label which for application extensions is FF. The next value is the block size which tells you how many bytes there are before the actual application data begins. This byte value should be 0B which indicates 11 bytes. These 11 bytes hold two pieces of information. First is the application identifier which takes up the first 8 bytes. These bytes should contain ASCII character codes that identify to which application the extension belongs. In the case of the example above, the application identifier is "NETSCAPE" which is conveniently 8 characters long. The next three bytes are the application authentication code. The spec says these bytes can be used to "authenticate the application identifier." With the Netscape 2.0 extension, this value is simply a version number, "2.0", hence the extensions name. What follows is the application data broken into data sub-blocks. As with the other extensions, the block terminates when you read a sub-block that has zero bytes of data.
With this information in hand, I went over to this handy online hex dump tool and uploaded your file. Here are the first 87 bytes (the rest of the file is excluded for irrelevance and brevity):
file name: b1dKD.gif mime type: 0000-0010: 47 49 46 38-39 61 68 01-64 01 77 ff-00 21 ff 0b GIF89ah. d.w..!.. 0000-0020: 4e 45 54 53-43 41 50 45-32 2e 30 03-01 01 00 00 NETSCAPE 2.0..... 0000-0030: 21 fe 33 43-72 65 61 74-65 64 20 77-69 74 68 20 !.3Creat ed.with. 0000-0040: 74 68 65 20-57 6f 6c 66-72 61 6d 20-4c 61 6e 67 the.Wolf ram.Lang 0000-0050: 75 61 67 65-20 3a 20 77-77 77 2e 77-6f 6c 66 72 uage.:.w ww.wolfr 0000-0057: 61 6d 2e 63-6f 6d 00 am.com.
This data constitutes the first few metadata records in your image. The first 13 bytes are just a bit of information about what type of image it is. Then we get to the interesting bit: the Netscape looping extension I quoted above. Per that format, the information we're interested in are the bytes at offsets 17 and 18 - the number of times the loop should be executed...
0000-0020: 4e 45 54 53-43 41 50 45-32 2e 30 03-01 01 00 00 NETSCAPE 2.0.....
There they are; in bold. Little-endian means the least-significant byte comes first, so that gives us the value 0001 in hex, which is conveniently also 1 in decimal notation.
Thus, the file you uploaded explicitly specifies that the animation should loop exactly once.
I've provided a version of the GIF without this restriction, for your convenience: https://i.stack.imgur.com/FKwNk.gif