it's not a bug; it's a feature

I have spent more time than I care to admit chasing a couple of differences between Chrome and Firefox. For several days until a few minutes ago (see timestamps at bottom), I thought I'd found a Firefox bug. As of now, I would still call Firefox's behavior a "bug," but it seems to be a known behavior. I most certainly did and do have to work around this "behavior."

First, I assumed the bug had something to do with drag and drop. I had a 5 step reproduction scenario. Then the first person whom I asked to give me a sanity check discovered that just changing the dropdown (select option(s)) and reloading had the same result. After a few minutes of looking through various versions that my apprentice, Rashad Persons, and I worked on, it would seem that having an initial "selected" attribute is the point where the "bug" / "behavior" comes in. If there is no "selected" attribute and you refresh the page, the option goes back to the first one upon reload.

The first answer by Eliran Malka addresses this well. From the user's point of view, control-F5 will solve the problem. This is a "hard reset." Programatically, I suspect that Location.reload(true); will solve the problem if you put it within a handler for "onunload." I may have more on this in a few days or weeks or eventually.

Without understanding this "hard reload," my solution (not publicly available) had been to handle "onunload," send the browser to an almost-blank page, and have that page load JS to go back to the original page.

drag and drop in Firefox versus Chrome

Note the line in this source code, "event.dataTransfer.setData('application/x-moz-node', row);" Firefox won't drag without that line and the supporting code to tell FF that you're dragging the row and not the td element or select element. Chrome needs neither that line nor the getRow() code. Chrome seems to assume you're dragging whatever has the "draggable" tag. This issue also caused me a great deal of grief.

(Actually, I'm not entirely certain that the getRow() code is needed, but I'm not going back to find out.

It may be that in least one of these cases FF is "right" and Chrome is "wrong." That's a research project for another day or never. Maybe an apprentice can do it.

I'll leave the following as-is. This page is still a good example of drag and drop. Note above that the problem (it was a "problem" to me) is simpler than 5 steps.

an extra thank you

My apprentice Rashad Persons inspired me to try to get to the bottom of this. My original mission statement was that we were going to try to characterize a Firefox bug, although it seems that hunt is over. Once I'm over the enormous frustration of all this, I'll probably be happy to have gotten to the bottom of it.

reproducing a Firefox reload bug (what I thought was a bug, and it's still a good example of drag and drop)

1. Change both dropdowns, below, to the opposite of the original. (Otherwise put, change them to the "...NOT..." option.)
2. Drag the rows up and down so that they change positions. (Dragging is a bit touchy sometimes, but hopefully you'll get it.)
3. Repeat the drag several times
4. Refresh the page
5. As the options indicate, you should not see the non-original options. If you do, the page isn't reloading properly.

I don't see any other option but a bug in Firefox.

I am experiencing this problem in Firefox Quantum 67.0, 64 bit, "Mozilla Firefox for Ubuntu canonical - 1.0," in Ubuntu Linux 18.04.2.

Chrome does what I expect upon refresh--the page refreshes rather than getting "stuck."