The browser toolbar often jitters in and out, especially when scrolling horizontally

NEW
Unassigned

Status

Firefox OS
Gaia::System::Browser Chrome
3 years ago
3 years ago

People

(Reporter: cwiiis, Unassigned)

Tracking

({polish})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [systemsfe])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Something quite annoying with the expanding rocketbar, if you scroll slowly, or horizontally, the toolbar often jitters in and out of position.

There are a few of ways I can think of fixing this;

1- Just add a timeout before re-showing the bar. Perhaps in combination with a more aggressive axis-lock to help horizontal scrolling.
2- Use position: sticky to introduce a 'dead-zone' where the toolbar won't reappear. Perhaps in combination with 1.

I've been thinking about this for a while and was all set on (2), but having just implemented it, I didn't consider that while you scroll in this deadzone, nothing appears to move (the container frame is scrolling, but the browser frame is fixed in position at this point).

Possibly we could remedy this by only having the dead-zone after the user has begun scrolling, though adding it while scrolling is in progress might produce some odd effect (speculation, I haven't thought through it enough to know either way).

Something that might throw things into method (1)'s favour is if the no-clip browser frame extension still works/could work. If so, you would still see content when the toolbar doesn't appear and you scroll up, rather than possibly exposing blank area. I doubt it does though, and it may not be/probably isn't exposed to content.

I'm going to continue experimenting with (2) as I think it's a more elegant solution (the current patch is CSS-only, which I find pleasing :))
(Reporter)

Comment 1

3 years ago
Here's my branch for experimenting with (2): https://github.com/Cwiiis/gaia/tree/wip-remove-toolbar-jitter
(Reporter)

Comment 2

3 years ago
Here's a branch implementing (1): https://github.com/Cwiiis/gaia/tree/wip-remove-toolbar-jitter-with-timeout

This works and feels quite a lot better than (2) does at the moment, but also looks really janky. It exposes the top of the browser frame, as expected, but oddly, that frame seems to be scrolling synchronously? I don't know why that is, maybe a platform bug here?
(Reporter)

Comment 3

3 years ago
I've been experimenting with other techniques, but I've not found something adequate. I think to do this well, we need either:

- Better axis-locking during horizontal scrolling and perhaps some jitter smoothing on the platform side. This would involve no Gaia changes.

Or,

- Expose clipSubdocument to the browser element. This would allow the rendered area to not be clipped by the iframe bounds and so we could delay the show/hide of the toolbar without any nasty visual side-effects. (something like this: https://github.com/Cwiiis/gaia/tree/wip-remove-toolbar-jitter-locking)
(Reporter)

Comment 4

3 years ago
Created attachment 8583064 [details] [diff] [review]
WIP: Expose clipSubdocument to browser iframe

This exposes a clipSubdocument property, much like scrollgrab.

Unfortunately, it doesn't actually seem to work - Even forcing IgnoreViewportClipping to return true and ShouldClipSubdocument to return false for *all* frames, the browser frame in b2g's system browser still ends up clipped.

Not entirely sure what's happening here yet.
(Reporter)

Comment 5

3 years ago
After talking with kats about this, he made what I think is a better suggestion than everything I've tried/suggested so far;

We could introduce a stronger axis-lock at the extents of an axis, and perhaps only for scrollgrab layers to avoid any weirdness it may introduce elsewhere.

So basically when y=0 or y=max, The drag-threshold for that axis may temporarily increase, and axis-lock strength for the opposing axis may temporarily increase. And the same for the x-axis of course.

This would markedly improve the experience of horizontal scrolling with respect to toolbar jitter. This won't help jitter on vertical scrolling though, but I believe there are ways we can work around that in Gaia.

Leaving this assigned to me, but this isn't at the top of my priorities list.
(In reply to Chris Lord [:cwiiis] from comment #5)
> We could introduce a stronger axis-lock at the extents of an axis, and
> perhaps only for scrollgrab layers to avoid any weirdness it may introduce
> elsewhere.
> 
> So basically when y=0 or y=max, The drag-threshold for that axis may
> temporarily increase, and axis-lock strength for the opposing axis may
> temporarily increase. And the same for the x-axis of course.

Why is it sufficient to limit these changes to the extents of the axis (y=0 and y=max) - can't the toolbar jitter occur while you're in the middle of a page as well?
(Reporter)

Comment 7

3 years ago
(In reply to Botond Ballo [:botond] from comment #6)
> (In reply to Chris Lord [:cwiiis] from comment #5)
> > We could introduce a stronger axis-lock at the extents of an axis, and
> > perhaps only for scrollgrab layers to avoid any weirdness it may introduce
> > elsewhere.
> > 
> > So basically when y=0 or y=max, The drag-threshold for that axis may
> > temporarily increase, and axis-lock strength for the opposing axis may
> > temporarily increase. And the same for the x-axis of course.
> 
> Why is it sufficient to limit these changes to the extents of the axis (y=0
> and y=max) - can't the toolbar jitter occur while you're in the middle of a
> page as well?

On further thought, you're right... I forgot of course that it's possible (though unlikely) for the scrollgrab container to be in an intermediate state.
(In reply to Chris Lord [:cwiiis] from comment #7)
> (In reply to Botond Ballo [:botond] from comment #6)
> > (In reply to Chris Lord [:cwiiis] from comment #5)
> > > We could introduce a stronger axis-lock at the extents of an axis, and
> > > perhaps only for scrollgrab layers to avoid any weirdness it may introduce
> > > elsewhere.
> > > 
> > > So basically when y=0 or y=max, The drag-threshold for that axis may
> > > temporarily increase, and axis-lock strength for the opposing axis may
> > > temporarily increase. And the same for the x-axis of course.
> > 
> > Why is it sufficient to limit these changes to the extents of the axis (y=0
> > and y=max) - can't the toolbar jitter occur while you're in the middle of a
> > page as well?
> 
> On further thought, you're right... I forgot of course that it's possible
> (though unlikely) for the scrollgrab container to be in an intermediate
> state.

Ah, I was the one who misunderstood - we care about enacting these controls when the *scrollgrab container* is at one its extents (which is most of the time, as you point out), not the *page*. Makes sense now.

(A heads-up if you get to the stage of implementing this: APZ applies axis locking at the level of the target APZC, which is irrespective of scrollgrab (in this case, it will typically be the page's APZC, rather that the container's), so if the thing you want to check is whether the container is at one its extents, you'll have to look up the handoff chain. Feel free to ping me on IRC if this isn't clear.)
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1144611
(Reporter)

Comment 10

3 years ago
I don't think we have the necessary mechanisms to deal with this adequately yet. Being able to tie animation-progress to scroll position would help us here.
Assignee: chrislord.net → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.