Bug 1897075 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
It seems fixing a URI creates a new connection (or load, sorry if I'm messing up the terminology). This causes a failed HTTPS upgrade: HTTP -> HTTPS -> HTTP to start a new connection and some consumers don't understand that.

Specifically, ContentPage is waiting for nsIWebProgressListener.STATE_STOP to determine that a connection has completed at [XPCShellContentUtils.sys.mjs#80](https://searchfox.org/mozilla-central/rev/7a8904165618818f73ab7fc692ace4a57ecd38c9/testing/modules/XPCShellContentUtils.sys.mjs#80). Unfortunately, at [DocumentLoadListener.cpp#2395](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentLoadListener.cpp#2395) a new load is started when a URI fixup is taking place. This leads to a race between the replaced load finishing and the listener reacting to what it thinks is already complete.

There are [https://searchfox.org/mozilla-central/search?q=STATE_STOP&path=&case=false&regexp=false](a few other uses of STATE_STOP) so this might very well happen outside of tests.

Is there a better event for listeners to attach to or can we somehow make the downgrade transparent like the upgrade?
Revision 1 by
on 
It seems fixing a URI creates a new connection (or load, sorry if I'm messing up the terminology). This causes a failed HTTPS upgrade: HTTP -> HTTPS -> HTTP to start a new connection and some consumers don't understand that.

Specifically, ContentPage is waiting for nsIWebProgressListener.STATE_STOP to determine that a connection has completed at [XPCShellContentUtils.sys.mjs#80](https://searchfox.org/mozilla-central/rev/7a8904165618818f73ab7fc692ace4a57ecd38c9/testing/modules/XPCShellContentUtils.sys.mjs#80). Unfortunately, at [DocumentLoadListener.cpp#2395](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentLoadListener.cpp#2395) a new load is started when a URI fixup is taking place. This leads to a race between the replaced load finishing and the listener reacting to what it thinks is already complete.

There are a few other uses of STATE_STOP: https://searchfox.org/mozilla-central/search?q=STATE_STOP&path=&case=false&regexp=false so this might very well happen outside of tests.

Is there a better event for listeners to attach to or can we somehow make the downgrade transparent like the upgrade?

Back to Bug 1897075 Comment 0