Created attachment 8568774 [details] testcase 1 STR: 1. Load attached testcase in Nightly on Android. 2. Dismiss any initial alert dialogs. 3. Rotate your phone back & forth between Landscape & Portrait. EXPECTED RESULTS: An alert should pop up when you rotate your phone, to indicate that the viewport has resized. ACTUAL RESULTS: No alert. ALTERNATE STR: 1. Load about:firefox in portrait mode. 2. Rotate phone to landscape mode. EXPECTED RESULTS: Page fills new viewport. ACTUAL RESULTS: Right half of viewport is blank, until I touch screen, at which point the non-blank section scales up & awkwardly fills viewport like I've got a really-tall, zoomed-in portrait view. Firefox Beta (v36) -- installed from the Play store today -- gives EXPECTED RESULTS -- alerts show up, and about:firefox rotates nicely. Firefox Nightly (39.0a1 2015-02-24) gives ACTUAL RESULTS. No alerts on rotation, and about:firefox loads with weird blankness-followed-by-scaling as noted above.
I can't reproduce the bug in Firefox Nightly on Desktop, btw (in responsive design mode, clicking "rotate" button). I get a bunch of alerts for each of our incremental resizes there. I've only hit this in Nightly on Android. kats, do you know if this is a known issue, and/or if there's anyone else who should be CC'd /needinfo'd here?
We've had issues like this in the past but I don't think anything has changed between Beta and Nightly. And I'm not able to reproduce on my Nightly build on a Nexus 4 using the test case you attached. I get a dialog on initial load as well as on every rotation. about:firefox also seems to resize as I would expect on rotation. What device are you using?
I get EXPECTED RESULTS in latest Aurora (37, 2015-02-23), FWIW. It's possible there's something profile-dependent here, too (i.e. my Nightly profile might be busted somehow). I'm using a OnePlus One.
Darn -- I force-quit Nightly (using the app-switcher) and reopened it, and now I'm no longer hitting the bug. So I guess that means this is sporadic & may only happen in long-running sessions, or after some yet-to-be-isolated step is performed.
Just came to report this, it's been doing my head in.
Just to be sure it's the same issue -- does the problem go away after you force-quit firefox (by swiping it offscreen in the app-switcher)? (There may not be much we can do here until we've discovered semi-reliable steps that trigger this issue. If you can figure any out, please mention them!)
Nope, 100% reproducible on today's build 1. Go to mmangareader.me 2. Rotate phone 3. tap blank space to force resizing
STR from comment 7 WFM on a nexus 4 with nightly 2015-03-08. Paul, can you grab a logcat from when you rotate?
As far as I can tell this should never happen. The metadata local variable is assigned at , and that value comes from  which is implemented at . Even if for whatever reason there isn't a metadata in the WeakMap it should return a new empty metadata object. Somebody who can reproduce this would have to look at what's going on in the remote debugger to figure it out. I don't know if you're able to do that.  http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=7697ad4919e7#4667  http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=7697ad4919e7#4617  http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=7697ad4919e7#6426
If you tell exactly what to do, I'm happy to provide whatever data you require.
Created attachment 8576212 [details] [diff] [review] Patch
Kats - It looks like this was changed in bug 1127827 which landed in fx38. Can you request uplift once this patch lands?
Ah, thanks for tracking that down.
Sorry about that. I tried to audit all of the uses of WeakMap in the tree, but I guess I missed a place where it actually mattered.
Comment on attachment 8576212 [details] [diff] [review] Patch Approval Request Comment [Feature/regressing bug #]: bug 1127827 [User impact if declined]: sometimes rotation gets broken in that after rotation the viewport is messed up and content may not get resize events as expected. [Describe test coverage new/current, TreeHerder]: i was able to repro under somewhat contrived conditions and verified it was fixed there. not sure if we have STR for real-world scenarios that encounter this bug. [Risks and why]: pretty low risk, fennec-only change [String/UUID change made/needed]: none
FYI, this isn't fixed in the 0316 build, I'll try again in the 0317 build but as per the STR comment 7, this is still 100% reproducible right now.
The change didn't make it into the 0316 build. You can try the m-c build at http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-central-android-api-11/1426588411/ which should have it, or wait until tomorrow's nightly.
(In reply to Kartikaya Gupta (email:email@example.com) from comment #22) > The change didn't make it into the 0316 build. You can try the m-c build at > http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla- > central-android-api-11/1426588411/ which should have it, or wait until > tomorrow's nightly. I waited for 0317, tested and it's still not fixed.
Can you provide the changeset URL from about:buildconfig of the build you tested on?
triage drive-by, waiting to approve uplift until there's confirmation of the fix on nightly.
(In reply to Paul [pwd] from comment #25) > Built from https://hg.mozilla.org/mozilla-central/rev/436686833af0 That build doesn't have the fix. Please try on tomorrow's nightly, or the build I linked in comment 22.
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #27) > (In reply to Paul [pwd] from comment #25) > > Built from https://hg.mozilla.org/mozilla-central/rev/436686833af0 > > That build doesn't have the fix. Please try on tomorrow's nightly, or the > build I linked in comment 22. Ooh it's good to have it working properly again. I can indeed verify that the build in comment 22 doesn't feature this bug.