User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171130101246 Steps to reproduce: Create a new HTML-page with the following head-content, body can be left empty: <title>test</title> <meta name="keywords" content=""> <meta name="description" content=""> <style> body { background-color: green; } @media (min-width: 20cm) { body { background-color: red; } } </style> <script src="empty.js"></script> <meta name="viewport" content="width=device-width"> When loading this page with Firefox for Android on a smartphone (screen width < 20xm) the page is rendered red instead of green. When changing the screen orientation (horizontal/vertical) the color changes to green. Even if rotating back to the original screen orientation it keeps beeing green, as it should have been in the first place. Try out yourself on Firefox for Android: https://maxmaier.eu/ff/bad.html Swap the script with the meta tag and the issue is gone: <meta name="viewport" content="width=device-width"> <script src="empty.js"></script> Try out yourself: https://maxmaier.eu/ff/good1.html Or remove src="empty.js" from the script tag and issue is gone too: <script></script> <meta name="viewport" content="width=device-width"> Try out yourself: https://maxmaier.eu/ff/good2.html Or remove the first three meta tags (keywords, description and content-type) and the issue is gone too. Or move the style tag to the end of the head and the issue is gone. Or ... Testet with stable version (57.0.1) and nightly version (59.0a1) from the Play Store. Actual results: The site is rendered red after (re)loading. When changing the screen orientation (horizontal/vertical) the color changes to green. Even if rotating back to the original screen orientation it keeps beeing green, as it should have been in the first place. Expected results: The site should be rendered green.

If my mozregression run is correct, one of the two changesets in bug 1355721 comment 85 broke this, which seems a bit unexpected, but there we are (and in the end that patch *is* touching the CSS engine after all, even if it claims to be a Stylo patch and Stylo wasn't enabled by default on Android at that time). Since I can't reproduce this on Desktop, there must be something Android-specific involved here as well, though.

Looks like layout to me!

The tag <meta name="viewport" content="width=device-width"> takes effect here: https://searchfox.org/mozilla-central/rev/41925c0b6c6d58578690121de439d2a8d3d690f3/dom/base/nsDocument.cpp#7865-7867 My guess would be that there is some code path triggered by parsing <script> tag (maybe network request?) which leads to setting a premature viewport info before <meta name="viewport"> is actually parsed. The change in bug 1355721 may be related for its adding some font set flush code, but I consider it unlikely to cause this. One way to fix this would be tracking how do we get to nsDocument::GetViewportInfo() when when we parse <script>. Another approach (which you can either call it a wallpaper, or a fundamental solution) is to set viewport info again when a valid <meta name="viewport"> is observed if one has been set before.

I took a look today at this, and it makes sense that bug 1355721 is the regressor. The presence of the <script> causes a flush before the shell is initialized. That makes the code from bug 1355721 set up all the media query state and all that. When the HTML parser sees the viewport meta change, it goes properly through: https://searchfox.org/mozilla-central/rev/a5abf843f8fac8530aa5de6fb40e16547bb4a47a/layout/base/MobileViewportManager.cpp#131 And calls SetVisibleArea and all that, but the shell is not initialized yet! Which means that https://searchfox.org/mozilla-central/rev/a5abf843f8fac8530aa5de6fb40e16547bb4a47a/layout/base/nsPresContext.h#477 is never executed, and we never re-evaluate the media queries. I think the HasCachedStyleData check is just bogus, I'll try to figure out how to remove it without doing wasted work on flushes. I actually wonder if this is related to bug 1428236.

Too late to fix for 58, but we could still take a patch for 59 in the next week or so.

Well, Actually I guess I can test this automatically with an explicit width=foo on the viewport meta...

Oh, btw, I spent the day debugging fennec and just now I realize that we have a dom.meta-viewport.enabled pref that repros the test-case on desktop, sigh.

Comment on attachment 8949929 [details] Bug 1424878: Not having cached style data doesn't guarantee we don't need to update media query stuff. https://reviewboard.mozilla.org/r/219234/#review225002

Pushed by ecoal95@gmail.com: https://hg.mozilla.org/integration/autoland/rev/d6e7f810f7d3 Not having cached style data doesn't guarantee we don't need to update media query stuff. r=bz

Created web-platform-tests PR https://github.com/w3c/web-platform-tests/pull/9472 for changes under testing/web-platform/tests

Backed out changeset d6e7f810f7d3 (bug 1424878)for failing reftests related to usercss/usercss-uppercase.html a=backout on a CLOSED TREE push that caused the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=d6e7f810f7d301cb928b6ed16837a3b4f660a069 log for the failure: https://treeherder.mozilla.org/logviewer.html#?job_id=161516134&repo=autoland&lineNumber=13235. https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-classifiedState=unclassified&selectedJob=161516134&filter-searchStr=Windows%207%20debug%20Reftests%20with%20e10s%20test-windows7-32%2Fdebug-reftest-no-accel-e10s-8%20R-e10s(Ru8) backout: https://hg.mozilla.org/integration/autoland/rev/419a034ad4855c9e053e87f7c6bace189d854a81

I guess I'll wait until bug 1394233 gets review. My try run was with the patch there as well, thus I didn't notice the failure.

Pushed by ecoal95@gmail.com: https://hg.mozilla.org/integration/autoland/rev/88b42bd5847a Not having cached style data doesn't guarantee we don't need to update media query stuff. r=bz

Created web-platform-tests PR https://github.com/w3c/web-platform-tests/pull/9477 for changes under testing/web-platform/tests

Upstream web-platform-tests status checked passed, PR will merge once commit reaches central.

Upstream web-platform-tests status checked passed, PR will merge once commit reaches central.

Upstream web-platform-tests status checked passed, PR will merge once commit reaches central.

Upstream web-platform-tests status checked passed, PR will merge once commit reaches central.

Upstream web-platform-tests status checked passed, PR will merge once commit reaches central.

Merging PR failed: 405 {u'documentation_url': u'https://developer.github.com/v3/pulls/#merge-a-pull-request-merge-button', u'message': u'Base branch was modified. Review and try the merge again.'}

Can't merge web-platform-tests PR due to failing upstream tests

Upstream PR merged

Can't merge web-platform-tests PR due to failing upstream tests

We're getting pretty late in the 59 Beta cycle. Is this severe enough to warrant backport consideration or can it ride the trains?

It's hot a recent regression, can probably ride the trains.

Upstream PR merged

Upstream PR merged

Upstream PR merged