a53ab6b3a7eed5db69a72f92f239ee8f958bd200: Bug 1458010 - Add ability to select multiple tabs using Ctrl/Cmd. r?jaws draft multiselect_ctrl_key
layely <ablayelyfondou@gmail.com> - Sat, 05 May 2018 03:56:23 +0000 - rev 793275
Push 109330 by bmo:ablayelyfondou@gmail.com at Wed, 09 May 2018 19:45:04 +0000
Bug 1458010 - Add ability to select multiple tabs using Ctrl/Cmd. r?jaws MozReview-Commit-ID: BHelQhtv7Gk
6b21561c008bba39182fac3b24a3f2d3f363e1f1: Bug 1335148 - Part 4: Remove unused max_decoded_image_kb pref. r?snorp draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 30 Mar 2018 18:54:48 +0200 - rev 793274
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +0000
Bug 1335148 - Part 4: Remove unused max_decoded_image_kb pref. r?snorp Since bug 1104622, that pref has in fact been unused, so us setting that value to 0 on memory pressure didn't really achieve anything. Instead, the SurfaceCache already does its own memory management and discards image surfaces when receiving a memory-pressure notification. MozReview-Commit-ID: 4aqvclgvLhX
c22ae0e383fe866fc82b5ac51b3614be14201d75: Bug 1335148 - Part 3: Notify Gecko and turn bfcache back on when Fennec memory pressure decays to 0. r?snorp draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 06 May 2018 13:40:05 +0200 - rev 793273
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +0000
Bug 1335148 - Part 3: Notify Gecko and turn bfcache back on when Fennec memory pressure decays to 0. r?snorp MozReview-Commit-ID: 6Oyu7Lx1gFQ
d75a0702c59d7939167f1c86c1409c4c00991fca: Bug 1335148 - Part 2: Introduce notification for end of memory pressure. r?gsvelto draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 30 Mar 2018 13:26:24 +0200 - rev 793272
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +0000
Bug 1335148 - Part 2: Introduce notification for end of memory pressure. r?gsvelto For Fennec on Android, if we haven't received memory pressure notifications from the OS for a certain amount of time (in the order of ~15 mins), we assume that we're no longer under memory pressure. In order to turn the bfcache back on when that happens, we now want to be able to forward this fact to Gecko as well. Unfortunately, the way memory pressure is tracked using an atomic variable doesn't easily allow to fully extend the existing priority rules between "new" and "ongoing" to include a new "stopping of memory pressure" event. Since we're not using Dispatch*Eventual*MemoryPressure on Android and therefore the queuing priority behaviour isn't actually relevant for us, we just ignore that and only enforce that a pending "new" memory pressure event takes priority over a "stop" event. MozReview-Commit-ID: 90C9KogUyvf
41f0f98720f0f5effea7ef825d928750d0edcd7c: Bug 1335148 - Part 1: Dynamically determine content viewer count on Android, too. r?snorp,bz draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 29 Mar 2018 21:51:13 +0200 - rev 793271
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +0000
Bug 1335148 - Part 1: Dynamically determine content viewer count on Android, too. r?snorp,bz The current limit of at most one bfcache entry on Android dates back to when Fennec was built for the Nokia N810, which had a whopping 128 MB of memory. Since a few years have passed since then and mobile device technology has evolved considerably, it should be safe now to allow a little more than that. Since web sites sizes might have grown somewhat as well compared to the figure of 4MB mentioned in CalcMaxTotalViweres(), though and to be absolutely on the safe side, we still tweak the formula when building for Android, though. If in the worst case even those assumptions turn out too generous, we will still be protected by the fact that - we temporarily disable the bfcache when the OS signals memory pressure, and - our contentViewerTimeout is set to a lower value than on Desktop, so bfcache entries will expire sooner MozReview-Commit-ID: 1A6d0Q6Mdx0
e55b288ca2dae63239b06d7d27599328711008a0: 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 793270
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
0c5f2f8df70b4526b926e27e69b3a60b168a9d5b: 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 793269
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +0000
Bug 1414084 - Part 16 - Add some tests for the handling of PageActions. r?grisha MozReview-Commit-ID: EUl19vyK3Ra
ac22d3875fcff41228377830565104e705f91304: 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 793268
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
f672a6682fc722d5dd1aba1668a2b9606631e16c: 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 793267
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
d53f6ca3398d256f83167a0caf36a8fdc268711a: Bug 1414084 - Part 13 - Cache PageActions. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 26 Feb 2018 21:50:50 +0100 - rev 793266
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
1555ae93cbb3f80a379b8248cfb957dd666b71c5: 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 793265
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +0000
Bug 1414084 - Part 12 - Add some tests for the processing of Menu messages. r?grisha MozReview-Commit-ID: D8Aujo1PgIk
e4174d22aef81ebcf976ea0bf0afdabf63c7e0e8: 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 793264
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
7dc716a849447aeb3617c27a473aa397c8a96c7f: 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 793263
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
215de5566178beead53281011ec21d08f4c70588: 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 793262
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
b8651588e74578a882e60fff8eaf28ddd43079bc: 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 793261
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
7d6ed9f24aaf7d1cf7fb235d1e0b0ee8529c8603: 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 793260
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
6d6310d8d63ed08a43191ad76a20f98a280efe79: 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 793259
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
3610b53107b234ec22f5ba9abfc6da55411f55ca: 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 793258
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
cdbcf8726a3674ddfb5203cdd7dd4fa48a71a1c0: 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 793257
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +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
ae452ff00396f7e20608a750b8f5834a1542f66e: 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 793256
Push 109329 by mozilla@buttercookie.de at Wed, 09 May 2018 19:44:41 +0000
Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r?grisha MozReview-Commit-ID: 7nEhAUxOIsW
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip