Closed Bug 1134021 Opened 5 years ago Closed 5 years ago

[ShadowDOM] Scrollable elements are clipped and hit testing assumes no scrolling


(Core :: Layout, defect, P1)

Gonk (Firefox OS)



blocking-b2g 2.5+
Tracking Status
firefox39 --- fixed
b2g-v2.1 --- wontfix
b2g-v2.2 --- wontfix
b2g-master --- fixed


(Reporter: drs, Assigned: wchen)



(Whiteboard: [spark])


(3 files)

Reduced test case:

This bug only occurs on B2G. It also occurs on Geckos for both v2.2 and v3.0.

On desktop, the scrollable region containing "aaa ... [x100]" is scrollable and behaves as expected.

On v3.0 from today, the scrollable region is completely unscrollable.

On v2.2, the scrollable region is scrollable, but is clipped after a few hundred px and events such as "click"'s are always from the origin, {0, 0}. For example, if I scroll down 100px and then tap at the top left of the scrollable region, my event should be somewhere around {0, 100}, but instead, it's at {0, 0}.

William, could you take a look at this? Kartikaya (:kats) says that this is unlikely to be an issue with APZ.

As a side note, we have fixed this in one of our apps improperly this way:
Flags: needinfo?(wchen)
Component: DOM → Layout
Priority: -- → P1
Whiteboard: [lightsaber]
Attached patch work aroundSplinter Review
Here is a work around that lets scrolling work but likely causes a bug somewhere else. It seems like the ScrollableLayerGuid for stuff in shadow DOM isn't getting the right PresShellId which is causing it to fail a comparison in APZCTreeManager::FindTargetNode.
Flags: needinfo?(wchen)
I'm surprised that failure to set the zoom constraints would result in failure to scroll. At most it should allow zooming when it shouldn't.

Does the shadow DOM stuff get a separate presShell or something? I know nothing about how it works.
Comment on attachment 8566947 [details] [diff] [review]
work around

This doesn't seem to fix the issue for me, even in the reduced test case. On m-c from today both with and without this patch, the region containing "aaa [...]" is unscrollable.
Flags: needinfo?(wchen)
Blocks: 1134025
This workaround in addition to attachment 8566947 [details] [diff] [review] seems to fix the issue for now.
I uploaded the wrong patch, I meant to upload the changes in Doug's patch with changes to GetTargetAPZC instead of UpdateZoomConstraints. The changes to UpdateZoomConstraints are unnecessary.

(In reply to Kartikaya Gupta ( from comment #2)
> Does the shadow DOM stuff get a separate presShell or something? I know
> nothing about how it works.

No, it doesn't. My guess is that wherever we are getting the doc shell, we are doing it in a way that doesn't work for shadow DOM content (e.g. GetCurrentDoc()->GetDocShell(), nodes in a shadow DOM don't have a current doc).
Flags: needinfo?(wchen)
(In reply to Kartikaya Gupta ( from comment #8)
> Oh I guess it might be
> APZCCallbackHelper.cpp?rev=abe8b4e23df0#247 - is it possible to get a
> domwindowutils for shadow dom content?

Yeah, it looks like that was it.
Assignee: nobody → wchen
Attachment #8567332 - Flags: review?(bugmail.mozilla)
Attachment #8567332 - Flags: review?(bugmail.mozilla) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Whiteboard: [lightsaber] → [ignite]
Whiteboard: [ignite] → [spark]
No longer blocks: spark
blocking-b2g: --- → spark+
blocking-b2g: spark+ → 2.5+
You need to log in before you can comment on or make changes to this bug.