FasTrak's custom MapQuest map never finishes loading in Firefox for Android, due to endless loop of resize -> reload
Categories
(Core :: Layout: Scrolling and Overflow, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
Details
STR:
- Visit https://www.bayareafastrak.org/en/tolls/retailmap.html in Firefox for Android
(or on desktop with RDM, with touch simulation activated (the little finger icon))
ACTUAL RESULTS:
The site loads and then immediately reloads, via this resize listener in its html:
$(window).on({
[...]
resize:function(e){
waitForFinalEvent("document.location.reload()", 200, "uniqueIdyyy");
}
});
EXPECTED RESULTS:
No such automatic/infinite reload.
It seems that in Firefox (and I think only in Firefox?) we trigger a resize event shortly after the page loads, which makes the site reload via that ^ listener, and this repeats forever; so the site is effectively unusable.
Chrome gives EXPECTED RESULTS.
Reporter | ||
Comment 1•2 years ago
|
||
Using mozregression on desktop with RDM, I go back to https://bugzilla.mozilla.org/show_bug.cgi?id=1521934 , which wasn't really a regression but rather was just a pref-flip (devtools.responsive.metaViewport.enabled
) to make RDM a bit more true-to-life for emulating mobile devices.
With that pref manually set to true, I get an older regression range which points to bug 1290420, which also seems to have been a change to make RDM more true-to-life for emulating mobile devices. i.e. Nightly 2018-10-04 is the first build where I can reproduce on desktop RDM, with devtools.responsive.metaViewport.enabled
manually set to true.
So: this isn't a regression from bug 1290420 or from the devtools.responsive.metaViewport.enabled
pref, but it does require those in order to have the right set of conditions to be able to repro on desktop.
This is reproducible in GeckoView Example App, but unfortunately we only save GVE builds for a year, so we can't go back further than May 2021 with those builds to see when this really regressed (on mobile).
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 2•2 years ago
|
||
hiro and/or botond, I wonder if this is something you've encountered before?
Obviously this "reload-on-resize" pattern is not-great; but it does seem to reveal that we seem to be sending a resize event here where Blink/WebKit are not, which is perhaps worth addressing if we can.
Reporter | ||
Comment 3•2 years ago
|
||
(Looks like bug 1528052 was similar, but its mitigation apparently isn't sufficient for this particular site. --> adding see-also.)
Description
•