Closed
Bug 844502
Opened 12 years ago
Closed 9 years ago
In landscape orientation, tab menu overlays content, page stuck resizing and shifting around (Nexus 4)
Categories
(Firefox for Android Graveyard :: Toolbar, defect)
Tracking
(firefox19 unaffected, firefox20 unaffected, firefox21 unaffected, firefox22 affected, fennec-)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox19 | --- | unaffected |
firefox20 | --- | unaffected |
firefox21 | --- | unaffected |
firefox22 | --- | affected |
fennec | - | --- |
People
(Reporter: aaronmt, Unassigned)
References
()
Details
(Keywords: reproducible, testcase)
Currently when a tab is opened alongside the tab-tray in landscape, pages seem to continuously resize and shift around on their own. I wonder if this a regression from the new horizontal tab-scroll in landscape. I only see this in landscape.
See video for the behaviour: http://www.youtube.com/watch?v=WA00L0_TglI
i) Head to bug URL: http://news.ycombinator.com or http://mozilla.com
ii) Rotate to landscape, open tab menu
--
Nightly (02/23)
LGE Nexus 4 (Android 4.2.2)
Reporter | ||
Comment 1•12 years ago
|
||
Also opening and closing the menu triggers this. I'm thinking it's the new landscape scroller causing this. Lucas?
Flags: needinfo?(lucasr.at.mozilla)
Summary: Regression: Page/viewport stuck resizing and shifting around in landscape → Regression: Page/viewport stuck resizing and shifting around in landscape; also via menu access
Comment 2•12 years ago
|
||
I could not reproduce this on my Galaxy Nexus using latest Nightly. To be honest, I can't think of any way this could be related to the new horizontal scrolling tabs tray.
Flags: needinfo?(lucasr.at.mozilla)
Reporter | ||
Comment 3•12 years ago
|
||
Ok, looks this goes back. Checking older builds now. This is fairly trivial to reproduce on the Nexus 4; but I can't reproduce on the Galaxy Nexus. On my Nexus 4, I just go to mozilla.com, rotate to landscape, open the tab tray and open and close the menu and content keeps shifting around.
Kats?
Comment 4•12 years ago
|
||
I can't think of anything offhand that would cause this, and I don't have an N4 to reproduce it. Regression range would be useful here.
Comment 5•12 years ago
|
||
Do you have reflow on zoom set?
Reporter | ||
Comment 6•12 years ago
|
||
Nope. Here's a video http://www.youtube.com/watch?v=zWK53qgX0hc&hd=1 showing the menu affect on content. Crazy.
Comment 7•12 years ago
|
||
So that looks like the LayerView is getting moved around as the menu is shown/hidden. CC'ing sriram.
Comment 8•12 years ago
|
||
We removed the tabs tray menu.
Status: NEW → RESOLVED
tracking-fennec: ? → ---
Closed: 12 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 9•12 years ago
|
||
You guys killed the menu. Now you killed my bug. :(
Reporter | ||
Comment 10•12 years ago
|
||
Actually I forgot this is still reproducible without the menu.
Nexus 4 -> http://mozilla.org, rotate to landscape, open tab menu, see page resize on its own
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reporter | ||
Comment 11•12 years ago
|
||
So on my Nexus 4 in landscape, the tab menu doesn't push content down. Instead, opening the tab menu opens on top.
Status: REOPENED → NEW
Reporter | ||
Updated•12 years ago
|
Summary: Regression: Page/viewport stuck resizing and shifting around in landscape; also via menu access → Regression: Page/viewport stuck resizing and shifting around in landscape (Nexus 4)
Reporter | ||
Comment 12•12 years ago
|
||
Seems this like has been around or is an OS issue; going back to mozilla-release (16) and this still exists. So far only seeing this on my Nexus 4; don't have any other Adreno 320 device.
Keywords: regression,
regressionwindow-wanted
Summary: Regression: Page/viewport stuck resizing and shifting around in landscape (Nexus 4) → In landscape orientation, tab menu overlays content, page stuck resizing and shifting around (Nexus 4)
Reporter | ||
Comment 13•12 years ago
|
||
So apparently this also only happens in one orientation of landscape (buttons at the top of the phone), turning the phone upside down so the buttons are at the bottom while still in landscape and the issue is gone.
Reporter | ||
Updated•12 years ago
|
tracking-fennec: --- → ?
Updated•12 years ago
|
Assignee: nobody → lucasr.at.mozilla
tracking-fennec: ? → 22+
Reporter | ||
Comment 14•12 years ago
|
||
Still only see this on the Nexus 4 and in the 'bad' landscape orientation (software buttons on the top of the phone) - I think I'd make this a tracking + based on that and not 22.
Lucas have you had a chance to try it on your Nexus 4?
STR: mozilla.com, rotate phone so software buttons are on top and open the tab menu (it doesn't push content down, it overlays over content).
Comment 15•12 years ago
|
||
Yep, I can reproduce this on Nexus 4 as described in comment #14.
Comment 16•12 years ago
|
||
Lucas - Any movement on this? It's in Beta now.
Flags: needinfo?(lucasr.at.mozilla)
Reporter | ||
Comment 17•12 years ago
|
||
^
Comment 19•12 years ago
|
||
Ok, after going through all our animation code, everything looks fine afaik. This is smelling like a driver bug on N4.
I could try to animate the margins of the LayerView but this won't be a trivial change. We'd be adding complexity to our code just to work around a bug that, as far as we know, is only happening on one device in a specific orientation.
Thoughts?
Comment 20•12 years ago
|
||
(In reply to Lucas Rocha (:lucasr) from comment #19)
> Ok, after going through all our animation code, everything looks fine afaik.
> This is smelling like a driver bug on N4.
>
> I could try to animate the margins of the LayerView but this won't be a
> trivial change. We'd be adding complexity to our code just to work around a
> bug that, as far as we know, is only happening on one device in a specific
> orientation.
>
> Thoughts?
I'm not that bothered by this bug (not having an N4 probably helps :)), but there would be some advantages to using the same code-path as the dynamic toolbar to animate the position - we could actually synchronise the animation if we wanted to, for example.
I think the easiest way of doing it like this would be to store an extra offset in GeckoLayerClient that gets added to the margin offset in syncViewportInfo - any time this offset is non-zero, input would be broken, but we don't allow input when we've scrolled the surface view out of place anyway, so that wouldn't be an issue.
I don't think it adds significant complexity over what we already have, but I do agree that it is more complex.
Comment 21•12 years ago
|
||
It's a bit more complicated than it looks. We currently animate (on scroll position) the parent of toolbar+layerview. Changing the animation to animate the margin offset in layerview means we'd have to find a way to animate the toolbar, the layerview (and maybe their parent) independently.
Comment 22•12 years ago
|
||
I don't think this is severe enough to be worth adding complexity to the animation handling. Plus, it doesn't cause any graphics corruption or anything more serious. It's just a slightly weird visual glitch on one specific device in a specific orientation. I recommend not tracking it.
tracking-fennec: 22+ → ?
Updated•12 years ago
|
tracking-fennec: ? → -
Updated•12 years ago
|
Assignee: lucasr.at.mozilla → nobody
Comment 23•9 years ago
|
||
I'm not able to reproduce this any more. When opening the tab tray it hides the content so the STR in comment 10 don't work any more. Closing WFM, feel free to reopen if you still see it.
Status: NEW → RESOLVED
Closed: 12 years ago → 9 years ago
Resolution: --- → WORKSFORME
Updated•4 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
•