insecurely loaded old document.write() sites with meta redirects are slow in https-first mode
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
People
(Reporter: support, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [domsecurity-backlog2])
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36
Steps to reproduce:
Speculative parsing appears to be really slowing down some old websites that use document.write. Redoing all the sites is not an option. Is there one HTML command we can add to top of the page, to stop speculative parsing for the rest of the page.
eg: <head><speculative_parsing="off"></head>
Actual results:
See http://www.corpsoft.com.au/ or see http://inet1.storeserver-14.com/catalogue/test/ very slow on new Firefox. Not slow on Edge, IE or Chrome. The site is old and redoing whole site not an option.
Expected results:
See edge, IE or Chrome.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
Do you have a profile showing the slowness? How have you identified the slowness being due to speculative parsing?
I don't see it being much slower than other browsers here on Linux. Going to profiler.firefox.com and taking a profile with the "Platform" preset would be really helpful.
Speculative parsing fails thrice at http://inet1.storeserver-14.com/catalogue/test/public/home.ehtml . http://www.corpsoft.com.au/index.html has a meta refresh, which is less efficient than a real redirect.
I don't see any particular evidence of HTML parsing being especially slow on this site.
|
||
Updated•3 years ago
|
Thanks for looking into this. Firefox is my favorite browser, so this issue is important. Also have speed issues on some other sites when in Private Mode, or 'Never Remember History' mode.
Ok - Did some further test and tried to do a profiler.firefox.com. Then discovered the speed in fine when tested under non-private mode.
However when remember history is turned off the site slows down. eg: Go into private mode and then go to http://www.corpsoft.com.au/index.html
Then click on eg; Consumables. It's slow. Switch on 'Never Remember History' or use Private mode and the site is very slow. Don't use those features and the site is fast. What could cause this?
(In reply to Henri Sivonen (:hsivonen) from comment #3)
Speculative parsing fails thrice at http://inet1.storeserver-14.com/catalogue/test/public/home.ehtml . http://www.corpsoft.com.au/index.html has a meta refresh, which is less efficient than a real redirect.
I don't see any particular evidence of HTML parsing being especially slow on this site.
Only slow in private mode or 'Never Remember History' mode.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
Do you have a profile showing the slowness? How have you identified the slowness being due to speculative parsing?
I don't see it being much slower than other browsers here on Linux. Going to profiler.firefox.com and taking a profile with the "Platform" preset would be really helpful.
Can this tool be used in Private or 'Never Remember History' modes? Problem on appears in these modes.
|
||
Comment 7•3 years ago
|
||
I can reproduce the issue in Nihtly98.0a1 Windows10 Private window.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=87c6360e23c21705b112dda28895c50d0280da75&tochange=10bc715228c379d46953ff4581d4fbf72141218d
Setting dom.security.https_first_pbm = false fix the issue.
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Comment 8•3 years ago
|
||
Thanks! Christoph do you know if there's something we could do about this?
|
|
||
Comment 9•3 years ago
|
||
(In reply to IS from comment #6)
Can this tool be used in Private or 'Never Remember History' modes? Problem on appears in these modes.
I think so yeah.
|
|
||
Comment 10•3 years ago
|
||
Set release status flags based on info from the regressing bug 1709838
|
||
Comment 11•3 years ago
|
||
Honestly I'm not sure if we're going to be able to fix this, given what https-first does and how these old-style sites work. https-ONLY mode works fine -- the site fails to load, of course, but then users can proceed with an exception and it's fine after that.
Maybe we could put a cap on a number of meta redirects we try to upgrade before giving up in https-first mode?
Some of the URLs above with longer paths seem to work ok after a short-ish inital delay, and in some tries once those were loaded going back to the original urls loaded faster. Probably caching, so when testing make sure you've disabled that.
|
||
Updated•3 years ago
|
|
||
Comment 12•3 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #11)
Maybe we could put a cap on a number of meta redirects we try to upgrade before giving up in https-first mode?
Yeah we could do a max-allowed-redirect reached kind of approach. We have the RedirectChain and also the MetaRedirect flag, both available on the loadinfo.
Description
•