e3c2615f94e2d67389635d09fbb3c8ffa14e449a: Bug 1371115 - Part 2: implements nsStyleGridLine type properties animatable. r?hiro draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Tue, 20 Jun 2017 10:12:55 +0900 - rev 599286
Push 65468 by bmo:dakatsuka@mozilla.com at Thu, 22 Jun 2017 22:28:14 +0000
Bug 1371115 - Part 2: implements nsStyleGridLine type properties animatable. r?hiro In this patch, implements following properties: * grid-column-end * grid-column-start * grid-row-end * grid-row-start MozReview-Commit-ID: 2iG6aeuFsE4
fce05295b6dfe07146f289f84473cea5338376a2: Bug 1371115 - Part 1: implements nsStyleCoord type properties animatable. r?hiro draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Tue, 20 Jun 2017 10:12:53 +0900 - rev 599285
Push 65468 by bmo:dakatsuka@mozilla.com at Thu, 22 Jun 2017 22:28:14 +0000
Bug 1371115 - Part 1: implements nsStyleCoord type properties animatable. r?hiro In this patch. implement following properties. * grid-auto-columns * grid-auto-rows * scroll-snap-points-x * scroll-snap-points-y MozReview-Commit-ID: 3XdA3pSGcsn
9f49b5cfb2f421e81870d2b599f07412fd2aac60: Bug 1358907 Part 2 Avoid reading XPI database at startup draft
Andrew Swan <aswan@mozilla.com> - Thu, 18 May 2017 13:08:58 -0700 - rev 599284
Push 65467 by aswan@mozilla.com at Thu, 22 Jun 2017 22:28:11 +0000
Bug 1358907 Part 2 Avoid reading XPI database at startup Switch telemetry and experiments from AddonManager.getAddonsByTypes() to AddonManager.getActiveAddons() which gives us less detailed information in the environment during startup but also means we don't need to load the extensions database until startup is complete. MozReview-Commit-ID: 4SxdPHSPovB
1347f18bf194affa91714bf443707805fbe688de: Bug 1351783 part 19 - Rename Keyboard.h to KeyboardMap.h. r=masayuki draft
Ryan Hunt <rhunt@eqrion.net> - Thu, 15 Jun 2017 18:06:00 -0400 - rev 599283
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 19 - Rename Keyboard.h to KeyboardMap.h. r=masayuki This is a better name for the header that matches its main class. MozReview-Commit-ID: KSt9LVT3yRR
497bdf0e1d1287f0a9d71bb3037f008cf50f216b: Bug 1351783 part 18 - Add async keyboard scrolling information to about:support. r?kats draft
Ryan Hunt <rhunt@eqrion.net> - Thu, 15 Jun 2017 17:54:03 -0400 - rev 599282
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 18 - Add async keyboard scrolling information to about:support. r?kats MozReview-Commit-ID: LYEcRNgqZ35
c31bc0f5c265b67271b14386f55151be3aa5e623: Bug 1351783 part 17 - Do less work when apz.keyboard.enabled is false. r=kats draft
Ryan Hunt <rhunt@eqrion.net> - Tue, 06 Jun 2017 11:08:45 -0500 - rev 599281
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 17 - Do less work when apz.keyboard.enabled is false. r=kats When keyboard apz is disabled, we don't need to calculate focus targets and we don't need to update focus state. It should be harmless even if it's done, but I think it's good to not add something on this critical path that doesn't do anything. This commit also disable keyboard map generation in this case too for similar reasoning. This has the side effect that you can't turn on keyboard apz without doing a restart. MozReview-Commit-ID: LxmofT2g7qs
426e9a2b3d5eb9143f74e3881cc1a182ded5c1a6: Bug 1351783 part 16 - Perform async scrolling for keyboard events when possible. r?kats,botond draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 19:46:06 -0500 - rev 599280
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 16 - Perform async scrolling for keyboard events when possible. r?kats,botond This commit ties it all together by dispatching keyboard actions to scroll targets in response to keyboard inputs when we have current and valid focus state. MozReview-Commit-ID: G7rZiS3FH5e
b02717218b46daf255d35e04091c7982165040ed: Bug 1351783 part 15 - Hook up APZC for scrolling based on a KeyboardScrollAction. r?kats,botond draft
Ryan Hunt <rhunt@eqrion.net> - Tue, 06 Jun 2017 04:47:10 -0500 - rev 599279
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 15 - Hook up APZC for scrolling based on a KeyboardScrollAction. r?kats,botond This commit adds code for keyboard scroll animations and computing the delta needed for a keyboard scroll action. Keyboard scrolling behavior is more complex with scroll snapping, so we don't support async keyboard scrolling when we have scroll snap points. MozReview-Commit-ID: 97CpprCBp2A
895d7351af223410f03642e8c42b2033cd09f398: Bug 1351783 part 14 - Create a base class for WheelScrollAnimation. r=botond draft
Ryan Hunt <rhunt@eqrion.net> - Thu, 15 Jun 2017 04:31:50 -0400 - rev 599278
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 14 - Create a base class for WheelScrollAnimation. r=botond MozReview-Commit-ID: BtUJo5NAiTR
408f0f44ea74d1cf585f65b0449eda4f7bb074d9: Bug 1351783 part 13 - Add a function for determing if a ScrollSnapInfo has scroll snap points. r=botond draft
Ryan Hunt <rhunt@eqrion.net> - Thu, 15 Jun 2017 03:52:34 -0400 - rev 599277
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 13 - Add a function for determing if a ScrollSnapInfo has scroll snap points. r=botond MozReview-Commit-ID: 7Dj0RGfQFNC
0ea413048399e65be2cb135c7b663211aa003d4a: Bug 1351783 part 12 - Create and sync focus sequence numbers. r=kats,botond draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 19:45:31 -0500 - rev 599276
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 12 - Create and sync focus sequence numbers. r=kats,botond Focus can change at any moment in a document. This causes non-determinism and correctness problems for doing keyboard apz scrolling. To get around this, we will maintain deterministic behavior for focus changes initiated by input events and see if we can get away with more non-determinism for things like `setTimeout` In order to do this, we disable async keyboard scrolling when an input event is processed that could have a event listener. We then attach a sequence number to that input event and dispatch it to content. In content, we record the highest sequence number that we have processed from an event, and send that on each focus update. Using this, we can determine in APZ if we have a current focus target or if we are still waiting for an input event to be processed and focus to be reconfirmed. MozReview-Commit-ID: CWcu8YEFQz4
f181908cc4861507bde64cc883f1412a288d56b6: Bug 1351783 part 11 - Sync FocusTarget with WebRenderLayerManager. r?kats draft
Ryan Hunt <rhunt@eqrion.net> - Tue, 13 Jun 2017 02:43:59 -0400 - rev 599275
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 11 - Sync FocusTarget with WebRenderLayerManager. r?kats MozReview-Commit-ID: LxWt22XY5IE
24863831e2e8cd71fa97aa5ada21ccaaecf05680: Bug 1351783 part 10 - Create and sync the current FocusTarget on each layer transaction. r?kats,botond draft
Ryan Hunt <rhunt@eqrion.net> - Tue, 13 Jun 2017 02:00:49 -0400 - rev 599274
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 10 - Create and sync the current FocusTarget on each layer transaction. r?kats,botond This commit modifies PresShell and nsDisplayList to send a FocusTarget update on every layer transaction. Ideally we would like to send updates as often as possible, but this seems like it works well. This can be iterated on later, if necessary. MozReview-Commit-ID: 8PFqIOhzH77
54fb7209752bbd46ccb8a913788d028242fe93b1: Bug 1351783 part 9 - Disable a FocusTarget for an editable element. r=smaug draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 19:23:45 -0500 - rev 599273
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 9 - Disable a FocusTarget for an editable element. r=smaug This commit updates FocusTarget to disable itself if the focused element is editable, or is a part of an editable document. This is needed because we cannot do async scrolling when this is the case. MozReview-Commit-ID: Fl7W3967djG
5b4db2f72cefe05cedaf9f632ad8898fc4ccdce2: Bug 1351783 part 8 - Gather whether there are key listeners on the focused element. r?kats,smaug draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 19:22:16 -0500 - rev 599272
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 8 - Gather whether there are key listeners on the focused element. r?kats,smaug This commit updates FocusTarget to collect whether there are key listeners on the event target chain for the focused element. This is needed because we cannot do async scrolling when this is the case. MozReview-Commit-ID: FhSyF6ffZ4
c5e9ea2359feb4da940ea74a337054a10769c2da: Bug 1351783 part 7 - Create FocusState and FocusTarget types. r=kats,botond draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 19:12:22 -0500 - rev 599271
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 7 - Create FocusState and FocusTarget types. r=kats,botond This commit begins the work needed for tracking focus by creating two new classes, FocusTarget and FocusState. FocusState is created and used by APZCTreeManager to track the global focus information, while FocusTarget is created per layer tree and sent to APZ with local focus information. Between the two we are able to figure out what the correct scrollable layer is to use in response to a keyboard scroll. See the comment in `FocusState.h` for more details on the architecture and things needed in future patches to complete this. MozReview-Commit-ID: F75VZv3i9U2
bd8770f701277340d8fd012007d86dc7aabe47f8: Bug 1351783 part 6 - Create and send KeyboardMap to APZCTreeManager. r=kats draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 18:35:32 -0500 - rev 599270
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 6 - Create and send KeyboardMap to APZCTreeManager. r=kats This commit makes it so we initialize, send, and store a KeyboardMap for every APZCTreeManager for later keyboard event processing. This is a naive approach so it may be worth improving. MozReview-Commit-ID: CYTbLL3wRlC
0f7fa7995035961af8f52e3aa2bb7343c86ad6b9: Bug 1351783 part 5 - Add a KeyboardMap type. r=kats,masayuki draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 18:29:04 -0500 - rev 599269
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 5 - Add a KeyboardMap type. r=kats,masayuki The XBL bindings used for scrolling are managed by a nsXBLWindowKeyHandler. This class loads the handlers and has logic for searching through them to match a keyboard event. This commit adds a KeyboardMap class for storing KeyboardShortcuts and for mirroring the search logic of nsXBLWindowKeyHandler. MozReview-Commit-ID: 5BmFBilKTJy
6e7da49e9459a91cd2cb43bf172ad290c2583a71: Bug 1351783 part 4 - Add a KeyboardShortcut type. r=kats,masayuki draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 18:24:35 -0500 - rev 599268
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 4 - Add a KeyboardShortcut type. r=kats,masayuki Keyboard scrolling works by first dispatching a key event to the focused element of the page. It is then caught by a XBL binding put on the chrome event handler of every window. The XBL binding searches through all of its handlers to find one that can handle the keyboard event. The matching binding has a command string which is dispatched to the nsGlobalWindowCommands which dispatches to PresShell which does the actual scrolling. To do this asynchronously, we need a representation of the XBL handlers that can be applied to a KeyboardInput to get a KeyboardAction. This commit adds KeyboardShortcut for this purpose. KeyboardShortcut is designed to be compatible with nsXBLPrototypeHandler and to only handle the specific cases we care about for keyboard scrolling. If a XBL handler runs javascript or does anything else we cannot handle in an OMT situation, then we create a dispatch-to-content KeyboardShortcut. MozReview-Commit-ID: 1qzywS3QHVp
2db52d99287df29483ada0edc0fc739dd045d147: Bug 1351783 part 3 - Add a KeyboardScrollAction type. r=kats,masayuki draft
Ryan Hunt <rhunt@eqrion.net> - Mon, 05 Jun 2017 18:17:30 -0500 - rev 599267
Push 65466 by bmo:rhunt@eqrion.net at Thu, 22 Jun 2017 22:16:51 +0000
Bug 1351783 part 3 - Add a KeyboardScrollAction type. r=kats,masayuki The different types of keyboard scrolls are represented as command strings that are dispatched to nsGlobalWindowCommands. This commit adds a class to represent these command strings, along with a function to find the keyboard scroll action corresponding to a command string. MozReview-Commit-ID: 20vvYdzlYYT
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip