Closed
Bug 1136363
Opened 9 years ago
Closed 9 years ago
Viewport sometimes doesn't resize correctly (and resize event doesn't fire) when phone is rotated, in Firefox Android
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(firefox37 unaffected, firefox38 fixed, firefox39 fixed)
RESOLVED
FIXED
Firefox 39
Tracking | Status | |
---|---|---|
firefox37 | --- | unaffected |
firefox38 | --- | fixed |
firefox39 | --- | fixed |
People
(Reporter: dholbert, Assigned: kats)
References
Details
Attachments
(3 files)
436 bytes,
text/html
|
Details | |
350.81 KB,
text/plain
|
Details | |
1.14 KB,
patch
|
mfinkle
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•9 years ago
|
Summary: Pages don't resize correctly, when phone is rotated, in Firefox Android → Viewport doesn't resize correctly (and resize event doesn't fire) when phone is rotated, in Firefox Android
Reporter | ||
Comment 1•9 years ago
|
||
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?
Flags: needinfo?(bugmail.mozilla)
Keywords: regression
Assignee | ||
Comment 2•9 years ago
|
||
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?
Flags: needinfo?(bugmail.mozilla)
Reporter | ||
Comment 3•9 years ago
|
||
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.
Reporter | ||
Comment 4•9 years ago
|
||
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.
Summary: Viewport doesn't resize correctly (and resize event doesn't fire) when phone is rotated, in Firefox Android → Viewport sometimes doesn't resize correctly (and resize event doesn't fire) when phone is rotated, in Firefox Android
Reporter | ||
Updated•9 years ago
|
OS: Linux → Android
Hardware: x86_64 → ARM
Version: unspecified → Trunk
Reporter | ||
Updated•9 years ago
|
Keywords: regression
Comment 5•9 years ago
|
||
Just came to report this, it's been doing my head in.
Reporter | ||
Comment 6•9 years ago
|
||
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!)
Comment 7•9 years ago
|
||
Nope, 100% reproducible on today's build 1. Go to mmangareader.me 2. Rotate phone 3. tap blank space to force resizing
Assignee | ||
Comment 8•9 years ago
|
||
STR from comment 7 WFM on a nexus 4 with nightly 2015-03-08. Paul, can you grab a logcat from when you rotate?
Comment 9•9 years ago
|
||
Here you go Kats.
Assignee | ||
Comment 10•9 years ago
|
||
I see this in the log on a rotation: [JavaScript Error: "TypeError: metadata is undefined" {file: "chrome://browser/content/browser.js" line: 4668}] That's probably causing the problem, but I'm not sure why that's happening.
Assignee | ||
Comment 11•9 years ago
|
||
As far as I can tell this should never happen. The metadata local variable is assigned at [1], and that value comes from [2] which is implemented at [3]. 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. [1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=7697ad4919e7#4667 [2] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=7697ad4919e7#4617 [3] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=7697ad4919e7#6426
Comment 12•9 years ago
|
||
If you tell exactly what to do, I'm happy to provide whatever data you require.
Assignee | ||
Comment 13•9 years ago
|
||
I ran into this undefined metadata error while trying to run reftests on Fennec. I added some logging and the first time it hit it was on a valid document passed in to getMetadataForDocument, so as far as I can tell it's a WeakMap bug of some sort. 03-11 15:48:06.694 I/Gecko (17136): nsWindow: 0x84425600 OnSizeChanged [768 1038] 03-11 15:48:06.704 D/GeckoBrowser(17136): returning metadata [undefined] for document [[object HTMLDocument]] 03-11 15:48:06.714 W/GeckoConsole(17136): [JavaScript Error: "TypeError: metadata is undefined" {file: "chrome://browser/content/browser.js" line: 4668}] However we can probably work around it in browser.js.
Assignee | ||
Comment 14•9 years ago
|
||
Assignee: nobody → bugmail.mozilla
Attachment #8576212 -
Flags: review?(mark.finkle)
Updated•9 years ago
|
Attachment #8576212 -
Flags: review?(mark.finkle) → review+
Comment 15•9 years ago
|
||
Kats - It looks like this was changed in bug 1127827 which landed in fx38. Can you request uplift once this patch lands?
Assignee | ||
Comment 16•9 years ago
|
||
Ah, thanks for tracking that down.
Blocks: 1127827
status-firefox37:
--- → unaffected
status-firefox38:
--- → affected
status-firefox39:
--- → affected
Assignee | ||
Comment 17•9 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/2c2b67d059d9
Comment 18•9 years ago
|
||
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 19•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/2c2b67d059d9
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 39
Assignee | ||
Comment 20•9 years ago
|
||
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
Attachment #8576212 -
Flags: approval-mozilla-aurora?
Comment 21•9 years ago
|
||
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.
Assignee | ||
Comment 22•9 years ago
|
||
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.
Comment 23•9 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.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.
Assignee | ||
Comment 24•9 years ago
|
||
Can you provide the changeset URL from about:buildconfig of the build you tested on?
Comment 25•9 years ago
|
||
Built from https://hg.mozilla.org/mozilla-central/rev/436686833af0
Comment 26•9 years ago
|
||
triage drive-by, waiting to approve uplift until there's confirmation of the fix on nightly.
Assignee | ||
Comment 27•9 years ago
|
||
(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.
Comment 28•9 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Assignee | ||
Comment 29•9 years ago
|
||
Great, thanks!
Updated•9 years ago
|
Attachment #8576212 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•