Closed Bug 844502 Opened 10 years ago Closed 6 years ago
In landscape orientation, tab menu overlays content, page stuck resizing and shifting around (Nexus 4)
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)
Also opening and closing the menu triggers this. I'm thinking it's the new landscape scroller causing this. Lucas?
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
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.
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?
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.
Do you have reflow on zoom set?
Nope. Here's a video http://www.youtube.com/watch?v=zWK53qgX0hc&hd=1 showing the menu affect on content. Crazy.
So that looks like the LayerView is getting moved around as the menu is shown/hidden. CC'ing sriram.
We removed the tabs tray menu.
Status: NEW → RESOLVED
tracking-fennec: ? → ---
Closed: 10 years ago
Resolution: --- → INVALID
You guys killed the menu. Now you killed my bug. :(
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 → ---
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
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)
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.
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.
Assignee: nobody → lucasr.at.mozilla
tracking-fennec: ? → 22+
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).
Yep, I can reproduce this on Nexus 4 as described in comment #14.
Lucas - Any movement on this? It's in Beta now.
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?
(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.
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.
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+ → ?
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: 10 years ago → 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.