mozilla :: #apz

21 Apr 2017
15:42rhuntkats: have time to talk about keyboard apz telemetry?
15:42katsrhunt: sure
15:43rhuntkats: so my understanding is that we want to know the percentage of pages that could benefit from keyboard apz?
15:43rhuntand the conditions that disqualify a page for this probe is a non-passive key event on the root of the page or root scrollable?
15:44katsrhunt: yup, that's correct
15:45katsrhunt: so in general i think we'll want to add a flag on the document object to record whether or not the document has such a listener. we set the flag when a listener is added, and then during document destruction we report the telemetry
15:45katsrhunt: there are other similar flags already, look in ~nsDocument
15:45rhuntkats: mark whether the document has this kind of listener or ever had the listener?
15:46katsrhunt: probably if it ever had the listener. in practice we'll probably disable apz once the listener is added and not bother re-enabling it
15:47rhuntkats: makes sense, what about mouse move events?
15:48katsrhunt: we can do the same thing for that. another flag on the document
15:48katsset it if a mousemove listener is added
15:48katsfor checking if listeners are added you'll probably want to hook into EventListenerManager::AddEventListenerInternal
15:48katsit has the type of event as well as EventListenerFlags which has a passive bit
15:49katsi believe each node gets its own EventListenerManager so you can probably find out from inside the EventListenerManager if it's owned by a root node
15:51katsrhunt: or maybe just set a flag in EventListenerManager once a non-passive keyboard listener is added, and then during nsDocument destruction you can pull the ELM for the root nodes and check if they have the flag set
15:51katsthat might be better. you wouldn't need the flag in nsDocument in that case
15:51rhuntkats: hm, do we need to worry about mousemoves on non root nodes?
15:52katsrhunt: yeah, mousemove listeners anywhere in the document
15:53katsrhunt: the mousemove case might be harder to handle. maybe start with the keyboard one first
15:53rhuntkats: what about key events? do those only go to the root?
15:53rhuntkats: or can only the root preventdefault scrolling?
15:54katsrhunt: key events go to whatever element has focus, i believe. we only plan to enable apz with keyboard on the root scrollframe, so that's the only one we care about in terms of preventdefault
15:55rhuntkats: okay, makes sense
15:56rhuntkats: so where does nsDocument fit into the dom? I've never really gotten how the dom classes are arranged
15:57katsrhunt: nsDocument represents a document, which is the root of a webpage. there's one for each tab/window/iframe
15:58katsso it's a handy place to record things that per-webpage
15:58katsrhunt: not sure if that answers your question
16:01rhuntkats: okay, i suppose that's pretty obvious :)
16:01rhuntkats: do you know what object[s] own a nsDocument?
16:02katsrhunt: hm. i think it's owned by the window (nsGlobalWindow) but i'm not sure. there should be pointers to it from any node within the document
16:03katshttps://wiki.mozilla.org/Gecko:Overview#DOM_.2F_Content has some not-very-useful info
16:13rhuntkats: hm, so what is the root scrollframe? is that always the document or do we have to traverse to find it?
16:19botondrhunt: the root scrollframe is a separate object of type nsIScrollableFrame
16:19katsrhunt: the root scrolling element is usually either the <html> (&quot;the document element&quot;) or the <body> (&quot;the body element&quot;). there is an abstraction which returns the appropriate one: http://searchfox.org/mozilla-central/source/dom/base/nsDocument.cpp#10593
16:19katsrhunt: the root scrollframe is the frame corresponding to the root scrolling element in the frame tree
16:21katswe often conflate the frame tree terminology (e.g. scrollframe) with the DOM tree terminology (e.g. adding a listener) so that can make things confusing
16:21katsthings like nodes, documents, events, listeners all belong to the DOM side of things
16:22katsso when we talk about &quot;registering a listener on the root scrollframe&quot; that really means &quot;registering a listener on the DOM node that corresponds to the root scrollframe, which is either the body element or the html element&quot;
16:24rhuntokay, that makes sense
16:24rhuntso do we need to worry about the root scroll element and the document or just the root scroll element?
16:25rhuntkats: ^
16:25katsrhunt: good question. both, i think
16:25katslet me check a bit
16:27katsrhunt: yeah both. any listeners that are added to the window object or the document object could also intercept the events on the way to the scrolling element and preventDefault them
16:27katsrhunt: we have some code that we use for APZ-aware listeners at the document level: http://searchfox.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#8621
16:27katsprobably will need something similar
16:27botondkats: is &quot;we only plan to enable apz with keyboard on the root scrollframe&quot; a &quot;first pass&quot; thing, or is that the end state?
16:28katsbotond: first pass, i think
16:28katsrhunt: the EventDispatcher::Dispatch call in that function builds a list of the things that can intercept the event. i think there&#39;s actually more than just the document. there&#39;s some chrome objects that can also do it, which are not exposed to web content
16:29botondkats: so later, we will want telemetry for key listeners on other elements as well?
16:29katsbotond: maybe
16:30katsbotond: actually i&#39;m not sure if the scrolling rules are different and more complex for scrolling things like textareas
16:30katswe might not want to do that in apz at all
16:30katsiframes and such we could probably do
16:30botondkats: yeah, i don&#39;t think we can do textareas
16:30botondkats: because in textareas scrolling moves the caret and scrolls by a line of text and things like that, and we can&#39;t really do that in apz
16:31botondkats: we iframes and regular scrollable divs should be fine
16:31katsyeah but determining if there are listeners on those might be quite hard
16:31katssince any ancestor element could do a preventDefault
16:32katswe might need an all-or-none approach there
16:32botondkats: indeed
16:34rhuntkats: so that code sends a &#39;null&#39; event to the document and grabs all the listeners that would intercept it and checks if they are okay or not?
16:34rhuntfrom event capturing down the tree
16:34rhuntit seems like we would need something similar for this probe?
16:34rhunthm
16:35katsrhunt: yeah exactly
16:36katsrhunt: it might be better to ask smaug before you start writing code. he might have better ideas on how to go about doing this
16:39rhuntkats: hm so one way could be, add a &#39;everHadNonPassiveKeyEvent&#39; flag to ELM, populate that when appropriate, then in ~nsDocument do a APZ-aware listener like function but check nodes for their ELM having &#39;everHadNonPassiveKeyEvent&#39;?
16:39rhuntkats: yeah I&#39;ll do that
16:40katsrhunt: that sounds reasonable
16:40katsrhunt: one think to check is if the dom nodes are still alive in ~nsDocument. you might have to do the check earlier before nsDocument is destroyed
16:41katss/think/thing/
16:42rbarkerkats: botond: dynamic toolbar v3 is in today&#39;s nightly :)
16:42rbarkercan&#39;t wait for it to hit beta to get bug reports...
16:43rhuntkats: ah yeah, good point
16:43botondrbarker: nice :)
16:43katsrbarker: nightly hasn&#39;t prompted for an update yet
16:43katsi guess i can force it
16:44rbarkerkats: Yeah, that&#39;s what I did.
16:44rbarkerwas curious if it had made it or not.
16:45katsrbarker: looks good! :)
16:45rbarkerthanks
16:46rhuntkats: so I suppose if a chrome object with a non passive key listener is added and removed before the end of the document, that wouldn&#39;t be caught
16:47katsrhunt: it should be, i think
16:47katsthe chrome object will still have a EventListenerManager
16:47katsand the flag will be set on that object
16:47rhuntkats: oh, meaning the chrome object is removed, not the event listener
16:48katsrhunt: hm, i don&#39;t think any of those chrome objects get removed
16:48katsthey&#39;re part of the page load machinery
16:49katsand anyway i don&#39;t expect those to have non-passive keyboard events. if they do we can probably fix that since they&#39;re coming from gecko itself
16:49rhuntkats: okay, yeah that makes sense
16:50rhuntkats: we don&#39;t have to worry about the root element or root scrollable element being removed, right? besides normal end of document clean up
16:50katsrbarker: i&#39;m playing around with my test page at https://people-mozilla.org/~kgupta/bug/1180295.html, and when i rotate to landscape a couple of the fixed-pos items seem cropped. are you seeing that too?
16:51katsrhunt: yeah i think we don&#39;t need to worry about that
16:51rbarkerlet me check
16:53rbarkerkats: You mean the fixed position boxes are cropping the text? I see that, but I see it in aurora too
16:53rbarkerand beta.
16:53katshm, indeed
16:53katsseparate bug then
16:53rbarkerand release.
16:54rbarkerso it looks like it has been busted for a while.
16:58katsrbarker: long-pressing to get the action bar (not floating) while the toolbar is hidden causes the page to slide down under the finger
16:59rbarkerkats: okay, that was hard to test because I don&#39;t have any older android devices left (They all died). Had to do all testing in the emulator. Will look into.
17:00katsrbarker: ok. i&#39;m on a Z3C using CyanogenMod 12.1 (~Android 5.1.1)
17:05rbarkerkats: okay, easy to reproduce in emulator. I think we need to just not do show toolbar from UI side with the fixed action bar. will file and try and get a patch up.
17:05katsrbarker: cool, thanks
17:11rbarkerkats: if you long press to select something and then scroll, does the selected word change or am I just seeing emulator weirdness? It doesn&#39;t happen on my device, only 4.3 emulator.
17:12katsrbarker: might just be emulator weirdness, i don&#39;t see that
17:13rbarkerkats: okay, thanks.
17:13rbarkerkats: the emulator is a pain, I have to restart fennec after a few long presses because they stop working. fun :)
17:13katsheh
19:11rbarkerkats: could you try this: https://people.mozilla.org/~rbarker/fennec-action-bar-fix.apk and see if it fixes your issue (when you have the time of course).
19:19katsrbarker: perfect
19:19rbarkerkats: great, thanks. Will get it landed ASAP :)
20:07botondmstange: is there a way for web content to discover the length of a scrollbar thumb?
20:40mstangebotond: no there is not
20:42botond(i just realized, that&#39;s actually not what i want)
22 Apr 2017
No messages
   
Last message: 155 days and 3 hours ago