1442b1bf2d6da08f710dca4e8324ef63b477774b: Bug 1513778, dragenter and dragover events don't need a frame for their default handling to occur, r=smaug
Neil Deakin <neil@mozilla.com> - Fri, 21 Dec 2018 11:10:54 -0500 - rev 451712
Push 35252 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:56:22 +0000
Bug 1513778, dragenter and dragover events don't need a frame for their default handling to occur, r=smaug
c43184f50b7ac431b0c8244af2d712a2a9492971: Bug 1496629 - use RefPtr rather than nsCOMPtr to avoid data race. r=kmag
Nathan Froyd <froydnj@mozilla.com> - Fri, 21 Dec 2018 11:03:30 -0500 - rev 451711
Push 35252 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:56:22 +0000
Bug 1496629 - use RefPtr rather than nsCOMPtr to avoid data race. r=kmag
f711b70e09eeca944f980937988bea94c66dcdb0: Bug 1515939 - Fix styling of the submenu used to add new search engines. r=dao
Paolo Amadini <paolo.mozmail@amadzone.org> - Fri, 21 Dec 2018 14:36:34 +0000 - rev 451710
Push 35252 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:56:22 +0000
Bug 1515939 - Fix styling of the submenu used to add new search engines. r=dao Differential Revision: https://phabricator.services.mozilla.com/D15198
bac5e091e27dfdafaa6635ee2990db8f0f5cb7ee: Bug 1512038 - Handle different batterystats output for Raptor power tests on Android 7, r=rwood.
Bob Clary <bclary@bclary.com> - Fri, 21 Dec 2018 06:12:19 -0800 - rev 451709
Push 35252 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:56:22 +0000
Bug 1512038 - Handle different batterystats output for Raptor power tests on Android 7, r=rwood.
b043f7f99f9761bda81fb981c42840260abd44a2: Bug 1512038 - Enable raptor-speedometer-geckoview-power for android-hw-{p2,g5} on try, r=rwood.
Bob Clary <bclary@bclary.com> - Fri, 21 Dec 2018 06:12:18 -0800 - rev 451708
Push 35252 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:56:22 +0000
Bug 1512038 - Enable raptor-speedometer-geckoview-power for android-hw-{p2,g5} on try, r=rwood. Rap-P treeherder group for Raptor power tests. Emit separate PERFHERDER_DATA for power in addition to the performance measurements. Use magic --host HOST_IP value to have framework load host ip from environment variable HOST_IP.
527fcd973d9fdeb1a6f5e9eed01aaa5ab55640f2: Bug 1515599 - Prevent android hardware tests from running when using try option syntax, r=ahal.
Bob Clary <bclary@bclary.com> - Fri, 21 Dec 2018 06:12:18 -0800 - rev 451707
Push 35252 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:56:22 +0000
Bug 1515599 - Prevent android hardware tests from running when using try option syntax, r=ahal.
74101900e7d484cc9ddcba2cd867ca172b961ea0: Bug 1512958 - Properly clean up produced tracks in DecodedStream. r=jya
Andreas Pehrson <apehrson@mozilla.com> - Fri, 21 Dec 2018 16:23:57 +0000 - rev 451706
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1512958 - Properly clean up produced tracks in DecodedStream. r=jya Differential Revision: https://phabricator.services.mozilla.com/D14584
1d4816ef6e013b44000d5c633245ec8effef810d: Bug 1512958 - Add mochitest. r=jya,jib
Andreas Pehrson <apehrson@mozilla.com> - Fri, 21 Dec 2018 16:23:55 +0000 - rev 451705
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1512958 - Add mochitest. r=jya,jib Differential Revision: https://phabricator.services.mozilla.com/D14583
b8a2ab65c47930c8c2fa1a80da1be46221aeb27b: Bug 1511235 - part3 : ensure video is visible before starting test r=jya,baku
Alastor Wu <alwu@mozilla.com> - Fri, 21 Dec 2018 06:40:10 +0000 - rev 451704
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1511235 - part3 : ensure video is visible before starting test r=jya,baku Add testing function to know whether video is visible or not. Differential Revision: https://phabricator.services.mozilla.com/D14667
93ad0a17cde451734b6be6116a23fcc14e0db2d4: Bug 1511235 - part2 : add test. r=jya,baku
alwu <alwu@mozilla.com> - Thu, 20 Dec 2018 20:01:46 +0000 - rev 451703
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1511235 - part2 : add test. r=jya,baku Add new webidl method for testing only and a test. Differential Revision: https://phabricator.services.mozilla.com/D13805
a5756686b400e8274b8395fa9365aed9f776cbd9: Bug 1511235 - part1 : suspend video decoding for video whose visibility state is UNTRACK. r=jya
alwu <alwu@mozilla.com> - Thu, 20 Dec 2018 20:02:24 +0000 - rev 451702
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1511235 - part1 : suspend video decoding for video whose visibility state is UNTRACK. r=jya If video has not been within the potential visible range (which is larger than viewport) yet, its visibility state won't be updated and would stay in 'UNTRACK'. As those kinds of video are still invisible to users, we don't need to decode any video frames, we can suspend their video decoding until they're going to be visible. Differential Revision: https://phabricator.services.mozilla.com/D13804
1f867de12312ea29fe968e7b23f743d3e9da87d5: Bug 1478776 - Part 10: Add internal VisualViewport resize/scroll events. r=botond,nika
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 20 Dec 2018 22:14:42 +0000 - rev 451701
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 10: Add internal VisualViewport resize/scroll events. r=botond,nika The VisualViewport events are all nice and shiny, but unfortunately not quite what is needed for the session store. Firstly, the spec wants the "scroll" event to be fired only when the *relative* offset between visual and layout viewport changes. The session store however records the absolute offset and as such is interested in when *that* changes. Secondly, again as per the spec the events don't bubble, and with the default DOMEventTargetHelper implementation they don't escape the VisualViewport during capturing, either. This means that any event listener must be added directly on the VisualViewport itself in order to capture any events. This might have been intended because the events use the same names as the normal "scroll"/"resize" events, and as such you cannot specify separate event listeners for VisualViewport and non-VisualViewport "scroll" events if both events end up being dispatched to the same element (you can only try to filter after the fact by looking at the originalTarget of the event). At the same time, the VisualViewport is attached to the inner Window, and so each time you navigate, you also get a different VisualViewport object. All of this might be totally fine from the perspective of a page script, because in that case you won't care anyway about what happens when the current page goes away. From the session store perspective on the other hand (especially Fennec's non- e10s session store design), this is rather unfortunate because we don't want to have to keep registering event listeners a) manually for each subframe b) each time the page navigates The event target chain problem could be solved by letting the scroll events escape the VisualViewport during the capturing phase (which the spec doesn't say anything about), but this would mean that any scroll listener attached to a window/browser/... that uses capturing will now catch both layout and visual viewport scroll events. In some cases this might even be beneficial, but in others (e.g. bug 1498812 comment 21) I'd like to specifically decide which kind of scroll event to capture. Having to look at event.originalTarget to distinguish the two kinds might be defensible in test code, but in case this distinction would be needed in production code as well, given the existence of a C++-based filtering helper in nsSessionStoreUtils for another use case where (scroll) events need to be filtered, JS-based scroll event filtering might be a bad idea. Additionally, in any case this wouldn't solve the fundamental conflict between the spec and the session store about *when* the "scroll" event should be fired in the first place. Hence I'd like to introduce a separate set of events with distinct event names, which will be dispatched according to the requirements of our internal users (i.e. currently the session store). To avoid potential web compatibility issues down the road, for now these events will be dispatched only to event listeners registered in the system group (allowing *all* Chrome event listeners cannot be done because checking the Chrome status of each event target might be too expensive for frequently dispatched events). Differential Revision: https://phabricator.services.mozilla.com/D14046
4d4e9b8110451b9393b44078e32d1c36b7c31968: Bug 1478776 - Part 9: Helper function for layout viewport scroll position in PresShell. r=botond
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 20 Dec 2018 21:35:55 +0000 - rev 451700
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 9: Helper function for layout viewport scroll position in PresShell. r=botond This changes the semantics of the relative visual viewport offset calculation in the PresShell slightly, in that a missing root scroll frame will no longer force the relative offset to zero, even if the visual viewport itself has a non- zero scroll position [1]. On the other hand, the visual viewport's own relative offset calculations already work that way today, in that layout and visual viewport scroll positions are retrieved separately and then subtracted from one another regardless of whether those values are actually valid or merely a fallback because the PresShell/scroll frame weren't available. [1] Though I'm not sure under what circumstances this could really be relevant. Differential Revision: https://phabricator.services.mozilla.com/D14686
767281b6922eda01f577939b69f988ab6efc9866: Bug 1478776 - Part 8: Add an event flag for dispatching to system group only. r=smaug
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 20 Dec 2018 21:35:39 +0000 - rev 451699
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 8: Add an event flag for dispatching to system group only. r=smaug The semantics of the VisualViewport resize/scroll events aren't quite what is needed for internal browser usage, so we need a separate set of events that can be used e.g. by the session store. To avoid future web compatibility issues, that event should be kept internal, however none of the existing options to achieve that are suitable: - mNoContentDispatch can actually end up being dispatched to content after all and as per its comment preferably shouldn't be used any more for new features - mOnlySystemGroupDispatchInContent would work perfectly, except that it shouldn't be used for frequent events, which the resize/scroll events arguably are - mOnlyChromeDispatch doesn't work for the Desktop session store's content script, plus it might have the same performance problems as mOnlySystemGroupDispatchInContent Therefore, I propose to introduce a new mOnlySystemGroupDispatch event flag, which skips the comparatively expensive IsCurrentTargetChrome() check and relies only on the event listener having been registered in the system group. Differential Revision: https://phabricator.services.mozilla.com/D14045
6f2e2faa3321fb36ac285310855c4bd3e25e8657: Bug 1478776 - Part 7: Tune scroll events to only fire when the *relative* offset changes. r=botond
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 20 Dec 2018 21:35:38 +0000 - rev 451698
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 7: Tune scroll events to only fire when the *relative* offset changes. r=botond Internally, Gecko stores and updates the *absolute* offset between the visual viewport and the page, however the spec demands that the scroll event be fired whenever the *relative* offset between visual and layout viewport changes. Differential Revision: https://phabricator.services.mozilla.com/D14044
63749e66f2665bfb64988809fbd541874084cfe1: Bug 1478776 - Part 6: Initial Visual Viewport event implementation. r=botond
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 20 Dec 2018 21:35:26 +0000 - rev 451697
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 6: Initial Visual Viewport event implementation. r=botond The event rate throttling mechanism is modelled on the logic for "scroll" events in nsGfxScrollFrame.cpp. That is 1. When a request to fire an event is posted to the VisualViewport, we create a new runnable for this and register it with the RefreshDriver. If we already have a pending runnable, calling VisualViewport->Post...Event() becomes a no-op. 2. When the RefreshDriver is ready, it executes the runnable, which in turn fires the actual event and then cleans itself up. To keep this patch manageable, we simply fire a scroll event every time the stored visual viewport offset is changed. Because we are storing the absolute offset of the viewport relative to the page, this behaviour doesn't match the spec, which demands that scroll events are fired only when the relative offset between visual and layout viewport changes. We'll fix this up in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D14043
24951c9d732d81bc1747f089c683e2ffecd78ea0: Bug 1478776 - Part 5: Define Visual Viewport event handlers. r=botond,Ehsan
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 21 Dec 2018 17:08:47 +0000 - rev 451696
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 5: Define Visual Viewport event handlers. r=botond,Ehsan As per https://wicg.github.io/visual-viewport/#the-visualviewport-interface. Differential Revision: https://phabricator.services.mozilla.com/D14042
b056dade814dc2018a7fb3114b21ab33301a44fe: Bug 1478776 - Part 4: Add basic tests for visual viewport events. r=botond
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 20 Dec 2018 21:35:04 +0000 - rev 451695
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 4: Add basic tests for visual viewport events. r=botond This will use the existing APZ basic pan/pinch-zoom tests to check that scrolling/zooming will also generate the expected visual viewport events. Because the various scroll-related events are throttled by the refresh driver and only fire once per tick, merely flushing APZ repaints is no longer enough. We now have to actually wait for the paints themselves, so we're sure that we've had an opportunity to receive the corresponding events, too. Differential Revision: https://phabricator.services.mozilla.com/D14041
e6b186bffed79a39f5a3694679ec853a4943ca8c: Bug 1478776 - Part 3: Forward todo/todo_is to APZ mochitests, too. r=botond
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 20 Dec 2018 21:34:57 +0000 - rev 451694
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 3: Forward todo/todo_is to APZ mochitests, too. r=botond Differential Revision: https://phabricator.services.mozilla.com/D14040
93a3c7fc4acea01c618a459f5502b638aa718a84: Bug 1478776 - Part 2: Add utility class for counting events. r=botond,masayuki
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 20 Dec 2018 21:34:50 +0000 - rev 451693
Push 35251 by ccoroiu@mozilla.com at Fri, 21 Dec 2018 21:54:30 +0000
Bug 1478776 - Part 2: Add utility class for counting events. r=botond,masayuki Differential Revision: https://phabricator.services.mozilla.com/D14039
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip