7a562412e07f8da36340c8909a25bcb127577601: Bug 1281907 - Part 1 - Include zoom level compensation in clip transform passed to caller. r?botond draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 24 Mar 2018 21:27:06 +0100 - rev 775927
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1281907 - Part 1 - Include zoom level compensation in clip transform passed to caller. r?botond If we don't do that, in the case of a root scrollbar the clip transform passed to our caller will incorrectly be scaled with the current content resolution. This means that that the position of the clip rect won't match the actual position of the scrollbar if the resolution isn't ~1.0, so the scrollbars will be clipped out of existence when the content is (pinch-) zoomed in or out. MozReview-Commit-ID: 5yXa9EpTJ2g
48e6fb0cb1005c72612d48c833a019b082d962fd: Bug 1447607 - Correctly init and update ElfLoader::Singleton::lastError r=glandium draft
James Willcox <snorp@snorp.net> - Fri, 30 Mar 2018 09:57:43 -0500 - rev 775926
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1447607 - Correctly init and update ElfLoader::Singleton::lastError r=glandium MozReview-Commit-ID: r1bclXdt4V
1e21e611c8b51056ceaf42910c5510532c9a10c5: Bug 1414084 - Part 17 - Fix setting of private browsing theme state. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 02 Mar 2018 18:01:28 +0100 - rev 775925
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 17 - Fix setting of private browsing theme state. r?grisha Previously, this wasn't noticeable since adding/removing a PageAction would call refreshPageActionIcons(), which would do the correct thing, but now a newly created PageActionLayout can start with an already pre-populated mPageAction- List, which means that the subsequently arriving call to setPrivateMode() will erroneously activate the private mode tinting for all PageActions that support it. MozReview-Commit-ID: EvNx1Q9vwZ5
6c2b530be7c1a7ea13e6f948a3c5ea26c1d1dff3: Bug 1414084 - Part 16 - Add some tests for the handling of PageActions. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 19 Mar 2018 20:27:01 +0100 - rev 775924
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 16 - Add some tests for the handling of PageActions. r?grisha MozReview-Commit-ID: EUl19vyK3Ra
1ed6a69fafd3929d6f7d1483fe8695fa35867496: Bug 1414084 - Part 15 - Correctly remove already resolved PageActions, too. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 03 Mar 2018 18:11:57 +0100 - rev 775923
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 15 - Correctly remove already resolved PageActions, too. r?grisha When a PageActions:Remove message arrives and we cannot simply forward it, we need to remove not just pending PageActions:Add messages, but also any already present PageActions objects that a former PageActionLayout had handed to us. MozReview-Commit-ID: 3jnGsmMuVfa
d7f947c9fa8675a9c7ad0743db52d24b47dfe893: Bug 1414084 - Part 14 - Rename isPwaAdded for more clarity. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 20:39:00 +0100 - rev 775922
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 14 - Rename isPwaAdded for more clarity. r?grisha Despite its name and the original purpose for which it was added, that function generically checks for duplicates among all PageActions, not just the PWA badge. MozReview-Commit-ID: Ae6FsLb9F3S
467b68a4d5583a90469400bf14e4a1ed52004147: Bug 1414084 - Part 13 - Cache PageActions. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 26 Feb 2018 21:50:50 +0100 - rev 775921
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 13 - Cache PageActions. r?grisha Since converting a PageAction message into an actual PageAction object also en- tails parsing the image data URL into a drawable, we leave that task to the PageActionLayout. This means that the PageAction cache needs to operate slightly differently than the MenuItem cache. First, we store all PageAction BundleEvent messages that arrive while no PageActionLayout is ready and then forward them en masse when one becomes available. Secondly, if the PageActionLayout is going away again, we then also take a list of already parsed PageAction objects for safekeeping. MozReview-Commit-ID: AcPPONXqe46
d6e63535e6246c937ebd6867821a8f5ece129375: Bug 1414084 - Part 12 - Add some tests for the processing of Menu messages. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 19 Mar 2018 20:06:32 +0100 - rev 775920
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 12 - Add some tests for the processing of Menu messages. r?grisha MozReview-Commit-ID: D8Aujo1PgIk
b6aab1d59a8f810828d118fce57f22020100d7de: Bug 1414084 - Part 11 - Use a Map for the MenuItemInfo list. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 18:07:16 +0100 - rev 775919
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 11 - Use a Map for the MenuItemInfo list. r?grisha Since all related EventDispatcher messages use UUIDs, it makes sense to store our MenuItemInfos in a Map, so we can access them directly by UUID instead of having to iterate over them until we've found the desired one. Since we want to preserve the order in which MenuItemInfos were added, we use a LinkedHashMap. MozReview-Commit-ID: BEtJ59tX59m
07aeaf30aae1a47d68aa5641a607cfa2723bcbc9: Bug 1414084 - Part 10 - Init MenuItemInfo list right from the start. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 17:47:33 +0100 - rev 775918
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 10 - Init MenuItemInfo list right from the start. r?grisha The small savings in initialising this on demand the first time a menu item is added, are not worth the additional complexity in null checks and the like. MozReview-Commit-ID: Lcz09Ds8NxJ
039d22a01958ad29f6d04e1b64fa48500a193a65: Bug 1414084 - Part 9 - Move add-on menu item cache out of BrowserApp. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 25 Feb 2018 22:22:37 +0100 - rev 775917
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 9 - Move add-on menu item cache out of BrowserApp. r?grisha Bug 832990 solved the issue of us losing the menu item cache if BrowserApp was destroyed, however the issue remains that we'll miss any Menu:... messages that are sent while BrowserApp doesn't exist, e.g. if Gecko is initially loaded through a GeckoView-based activity. Therefore we now move the menu item cache and the listener for those messages into a separate class, whose lifetime better matches that of Gecko. Apart from any necessary changes, we move the existing code as is. The only additional change is that we make addAddonMenuItemToMenu() static, because we can. MozReview-Commit-ID: BJleonLnjmo
c13b1a4292e4d7ca3e6cb651150f804733e491e8: Bug 1414084 - Part 8 - Unify menu item EventDispatcher messages. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 16:42:57 +0100 - rev 775916
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 8 - Unify menu item EventDispatcher messages. r?grisha As a final step, these can be merged as well. The same reasoning as in the previous patch applies with regards to additional functionality that isn't (yet) used by webextensions. MozReview-Commit-ID: Ezx2mQY0s85
307237e87bd1bfb475f2bc881ef1659c84ad7e2a: Bug 1414084 - Part 7 - Use one set of functions for managing MenuItems in the UI. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 14:17:03 +0100 - rev 775915
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 7 - Use one set of functions for managing MenuItems in the UI. r?grisha The original add-on functions have some additional capabilities regarding e.g. checkboxes, disabling the menu, etc. that right now aren't required for Webextensions (yet?), but in that case they will simply not be used - in any case BrowserActions.jsm controls what functionality is actually exposed to add-ons. MozReview-Commit-ID: DPT8gV2gb6q
0e75714acaa093b2a0bc04c1c1f8118d48ebd209: Bug 1414084 - Part 6 - Use only one list to store menu items added from Gecko. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 23 Mar 2018 19:58:18 +0100 - rev 775914
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 6 - Use only one list to store menu items added from Gecko. r?grisha Now that the UI code for handling both the old NativeWindow API and Web- extensions is more or less the same and both are using the same MenuItemInfo class, there's no longer any real need to keep items added through the two APIs in separate lists - in fact doing so makes it harder to preserve the ordering of menu items if the activity and its menu are destroyed and need to be re- created later on from the stored lists of MenuItemInfos. MozReview-Commit-ID: KlJdvO9WhhY
64f9616aa269cefe07eb2428e360bfabc38d9790: Bug 1414084 - Part 5 - Unify menu click event handling. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 14:24:15 +0100 - rev 775913
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 5 - Unify menu click event handling. r?grisha Now that both Webextensions and the NativeWindow API manage their onClick call- back handling by UUID, we can start using the same EventDispatcher message for both. MozReview-Commit-ID: J3RRXrwPdTI
9e90b2aacf127fb89ad0720a7eb046859c80075f: Bug 1414084 - Part 4 - Move menu item ID generation into the UI. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 15:43:27 +0100 - rev 775912
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 4 - Move menu item ID generation into the UI. r?grisha Since the NativeWindow API now only uses UUIDs as well when dealing with its consumers, we can leave generation of the menu to the Android UI code of Firefox. MozReview-Commit-ID: 1qDLDnePfFE
489e5476bc555078c5440a6bcd741e42fefe400d: Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 13:33:42 +0100 - rev 775911
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r?grisha MozReview-Commit-ID: 7nEhAUxOIsW
5c68d27f972d2d0a65116079c67b5a5d7cd76db9: Bug 1414084 - Part 2 - Use UUIDs for the NativeWindow menu API, too. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 13:26:16 +0100 - rev 775910
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 2 - Use UUIDs for the NativeWindow menu API, too. r?grisha At the moment, the code for handling of JS-created main menu items is more or less duplicated between the old NativeWindow API and Webextensions, with the only real difference being that the former communicates directly via menu item IDs, while the latter uses UUIDs for messaging between Gecko and the UI. By switching the NativeWindow API to using UUIDs as well, we will be able to start unifying this code again. As for backward compatibility - the return value of NativeWindow.menu.add is valid for the current session only, so no migration is necessary - the return value of NativeWindow.menu add was already effectively only an opaque value which only had real meaning for subsequent calls to menu.add, menu.update and menu.remove, so it shouldn't really matter whether we return a plain numeric ID or an UUID in string form - old-style add-ons are now unsupported for better or for worse and our one in- tree caller won't have any problems with this change MozReview-Commit-ID: HdRNhrx1pu7
98617d0fca80d3b6b6d2ad14eda475d6382efe9a: Bug 1414084 - Part 1 - No longer track MenuItemInfo "added" data. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 13:49:31 +0100 - rev 775909
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 1 - No longer track MenuItemInfo "added" data. r?grisha We no longer use that value anywhere, so we can just stop keeping track of it. MozReview-Commit-ID: D1IgX1t8SKI
c97ea83aa7be334a02bfa3287c8dabde829d00fb: Bug 1414084 - Part 0 - Cleanups. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 25 Feb 2018 20:53:01 +0100 - rev 775908
Push 104750 by mozilla@buttercookie.de at Sun, 01 Apr 2018 20:21:04 +0000
Bug 1414084 - Part 0 - Cleanups. r?grisha MozReview-Commit-ID: B3ZGN2X8JXH
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip