I couldn't reproduce the issue in the "wild". I think the problem occurs in the [fragment test because of that line](https://searchfox.org/mozilla-central/source/dom/security/test/https-first/file_fragment.html#37). AFAIK fragmentation navigations don't lead to page (re-)loads. That is probably the bug here since *http://* is the hardcoded scheme of the button location. As the author of that test case I am sorry for bad practice (that is a copy paste of my first tests I wrote during my time at firefox :D ), unsure if that is not a very unlikely case for the "wild".
Bug 1804684 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I couldn't reproduce the issue in the "wild". I think the problem occurs in the [fragment test because of that line](https://searchfox.org/mozilla-central/source/dom/security/test/https-first/file_fragment.html#37). AFAIK fragmentation navigations don't lead to page (re-)loads. That is probably the bug here since *http://* is the hardcoded scheme of the button location. As the author of that test case I am sorry for bad practice (that is a copy paste of my first test I wrote for firefox :D ), unsure if that is not a very unlikely case for the "wild".
I couldn't reproduce the issue in the "wild". But reproduced it with the linked test file. I think the problem occurs in the [fragment test because of that line](https://searchfox.org/mozilla-central/source/dom/security/test/https-first/file_fragment.html#37). AFAIK fragmentation navigations don't lead to page (re-)loads. That is probably the bug here since *http://* is the hardcoded scheme of the button location. As the author of that test case I am sorry for bad practice (that is a copy paste of my first test I wrote for firefox :D ), unsure if that is not a very unlikely case for the "wild".