searching for reviewer(grisha)
8bc5f3cdc25cb9754817ad75d9fa4e158f94042a: Bug 1414084 - Part 17 - Fix setting of private browsing theme state. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 02 Mar 2018 18:01:28 +0100 - rev 829759
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
f565a28721bf3a0ea5af7ce5ced737d82c7e8803: Bug 1414084 - Part 16 - Add some tests for the handling of PageActions. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 19 Mar 2018 20:27:01 +0100 - rev 829758
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +0000
Bug 1414084 - Part 16 - Add some tests for the handling of PageActions. r=Grisha MozReview-Commit-ID: EUl19vyK3Ra
c2580679282dae363a4ad1ce6f0c477ce00fc212: Bug 1414084 - Part 15 - Correctly remove already resolved PageActions, too. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 03 Mar 2018 18:11:57 +0100 - rev 829757
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
e8d7b4fd98387380219b879f8a8b211bb87095c7: Bug 1414084 - Part 14 - Rename isPwaAdded for more clarity. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 20:39:00 +0100 - rev 829756
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
a40e70bbfe1a544d577c10248251628c134f6b80: Bug 1414084 - Part 13 - Cache PageActions. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 26 Feb 2018 21:50:50 +0100 - rev 829755
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
3dcf1f67d7e476803f0d1daacdf7e1999f7e8724: Bug 1414084 - Part 12 - Add some tests for the processing of Menu messages. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 19 Mar 2018 20:06:32 +0100 - rev 829754
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +0000
Bug 1414084 - Part 12 - Add some tests for the processing of Menu messages. r=Grisha MozReview-Commit-ID: D8Aujo1PgIk
39819b958e01a5112566c760e888ea6f5521c8e3: Bug 1414084 - Part 11 - Use a Map for the MenuItemInfo list. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 18:07:16 +0100 - rev 829753
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
47963c0890519069e98cdc89330929b45d7cc79f: Bug 1414084 - Part 10 - Init MenuItemInfo list right from the start. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 17:47:33 +0100 - rev 829752
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
eb1ac381e2fb7b750482b48557ace56ef6c026f3: Bug 1414084 - Part 9 - Move add-on menu item cache out of BrowserApp. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 25 Feb 2018 22:22:37 +0100 - rev 829751
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
84bac01f3a351b774a556dbc47c3305a62e54153: Bug 1414084 - Part 8 - Unify menu item EventDispatcher messages. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 16:42:57 +0100 - rev 829750
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
98ed7d6f8a7ab6b35f7ee73e6f0f7db4393ecf2f: Bug 1414084 - Part 7 - Use one set of functions for managing MenuItems in the UI. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 14:17:03 +0100 - rev 829749
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
261e4bb6efd87af390d0575f2623e379f979341b: Bug 1414084 - Part 6 - Use only one list to store menu items added from Gecko. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 23 Mar 2018 19:58:18 +0100 - rev 829748
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
b6e63d47b9bbafb1bb58571d8abb8906d7a6977a: Bug 1414084 - Part 5 - Unify menu click event handling. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 14:24:15 +0100 - rev 829747
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
c82c7117206fc5310f9a05b41e80c8d3d58b5542: Bug 1414084 - Part 4 - Move menu item ID generation into the UI. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 15:43:27 +0100 - rev 829746
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
d2aa38b39fa086df117be768e0b8f57ea361ffdc: Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 13:33:42 +0100 - rev 829745
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +0000
Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r=Grisha MozReview-Commit-ID: 7nEhAUxOIsW
9fc1c87f952f325a19ee5f41849381aaa534b500: Bug 1414084 - Part 2 - Use UUIDs for the NativeWindow menu API, too. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 13:26:16 +0100 - rev 829744
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
65a6e2ffdbaefb0356bad502edfe03df52f102cd: Bug 1414084 - Part 1 - No longer track MenuItemInfo "added" data. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 13:49:31 +0100 - rev 829743
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +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
74feab038c3375df282b291682e0b1244c202f00: Bug 1414084 - Part 0 - Cleanups. r=Grisha
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 25 Feb 2018 20:53:01 +0100 - rev 829742
Push 118795 by xquan@mozilla.com at Thu, 16 Aug 2018 22:58:08 +0000
Bug 1414084 - Part 0 - Cleanups. r=Grisha MozReview-Commit-ID: B3ZGN2X8JXH
367cc1789169c8551a3613376251bda8a0ce4ed6: 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 826047
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
0c2a3e6971e22e4db4f4250a4c23596d0ea81695: 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 826046
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +0000
Bug 1414084 - Part 16 - Add some tests for the handling of PageActions. r?grisha MozReview-Commit-ID: EUl19vyK3Ra
8b23a8e60c63f91e1978d841f61ce5e287e788c8: 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 826045
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
e929da52d2f357e47bb7a481fb458bfc3f8a623f: 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 826044
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
02ad7923724d85a38f5e8238c1052bcb293ff9b6: Bug 1414084 - Part 13 - Cache PageActions. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 26 Feb 2018 21:50:50 +0100 - rev 826043
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
dcf8f85cfebeb4ab7250be49661b1c6aabfbac66: 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 826042
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +0000
Bug 1414084 - Part 12 - Add some tests for the processing of Menu messages. r?grisha MozReview-Commit-ID: D8Aujo1PgIk
55d6b2b6a71f77b9f394c6eb40d36447fd2f1c29: 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 826041
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
93252b3c24ce7d7ad1b2c759733f344167a47336: 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 826040
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
41898999e4c45e40323267acb742a0eb4cd2460f: 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 826039
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
9c7e6f0b8ec8be4af5c18002f9794c3955360f5f: 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 826038
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
ce54ba843a9afec8c8ea65bd498438d66fd4f80c: 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 826037
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
1334f97fe563a6814be5efb9143af29e95971b31: 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 826036
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
9b7ab9aebbb49f1f23037ddf2038491efe2be7ce: 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 826035
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
ad875bf96a10074195e42172c85c499ecbfd5a7d: 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 826034
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
8f0204936347a6c47c8ca76496c890fbc9a767ec: 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 826033
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +0000
Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r?grisha MozReview-Commit-ID: 7nEhAUxOIsW
dfcb677f68d79dfc153aa02919e5687e08b61c7e: 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 826032
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
db79bb2e6461546939c0b5c711498485bbdec44d: 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 826031
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +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
de31919b2decd5f77f2ffe3e1637622b637d8073: Bug 1414084 - Part 0 - Cleanups. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 25 Feb 2018 20:53:01 +0100 - rev 826030
Push 118234 by mozilla@buttercookie.de at Thu, 02 Aug 2018 20:54:10 +0000
Bug 1414084 - Part 0 - Cleanups. r?grisha MozReview-Commit-ID: B3ZGN2X8JXH
8902c9e7ecd2b9cd7e2f0f79f3c0bdcc64c6710a: 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 823892
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
3d32da755f021757770513b5ffb23872f62af05e: 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 823891
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +0000
Bug 1414084 - Part 16 - Add some tests for the handling of PageActions. r?grisha MozReview-Commit-ID: EUl19vyK3Ra
aa5fd217ec44e9234c186879b8666cf9c472f4e0: 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 823890
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
73af07e0d7456d324113079928b9910a08ca4bf5: 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 823889
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
b3b141829012f006aaeddd3b09f387120ffc5faf: Bug 1414084 - Part 13 - Cache PageActions. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 26 Feb 2018 21:50:50 +0100 - rev 823888
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
de83af1d10c5636294e8c2a93b9c192a91d0515f: 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 823887
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +0000
Bug 1414084 - Part 12 - Add some tests for the processing of Menu messages. r?grisha MozReview-Commit-ID: D8Aujo1PgIk
e64c101eff5ed12e98a3eb83224008b547c7aeb4: 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 823886
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
060b82ea32b1323dbf029cbb2d943f38f0bf5d23: 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 823885
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
f87beb9188f46e8336daf7d9b607c3bcf0e8c766: 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 823884
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
747887186a05d2d3ef3feedf957a104328d2f829: 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 823883
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
a7012f02b31f1ddb0432d86998077026e83fecdc: 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 823882
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
5e43f88947c297e93724613c2838e4350eed8ffb: 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 823881
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
98a4086d825e413a5a094538d25261ffc8804894: 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 823880
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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
574149a09c4cf8b27f80fc2d7857af6a56ea3c7e: 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 823879
Push 117809 by mozilla@buttercookie.de at Sun, 29 Jul 2018 18:19:15 +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