2ccf2382f20d22e5bb46d5b03a785255f44c631d: Bug 1335148 - Part 3 - 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 791877
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +0000
Bug 1335148 - Part 3 - Remove unused max_decoded_image_kb pref. r?snorp Since bug 1104622, that pref has actually 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
dca2482e16b10faff1700519e833e3c2ae894b22: Bug 1335148 - Part 2 - Re-enable bfcache when memory pressure drops down to 0. r?snorp,njn draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 30 Mar 2018 13:26:24 +0200 - rev 791876
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +0000
Bug 1335148 - Part 2 - Re-enable bfcache when memory pressure drops down to 0. r?snorp,njn Currently, once the memory pressure as tracked by our Android-side MemoryMonitor exceeds a certain level, we trigger Gecko's memory pressure mechanism, which in turn amongst other things also disables the bfcache. If we receive no new low memory notifications from the OS and Android-side memory pressure decays back to 0 (which currently will take at least 15 mins), we want to turn the bfcache back on, which requires a new notification in Gecko. 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
a3f88da426c4dedac583c300dfaf463a762031b3: 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 791875
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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 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
5f81f5082586fe9307ae3f95ea1de6623fe58089: 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 791874
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
701ef50b587fae458f263d1c6daac6ddb53db73c: 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 791873
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +0000
Bug 1414084 - Part 16 - Add some tests for the handling of PageActions. r?grisha MozReview-Commit-ID: EUl19vyK3Ra
e53fd23e761e336cebdd1a9f2a0ee130b0e6f107: 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 791872
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
4b1476e8ab41f3eec8f13467f9653d37be005ad0: 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 791871
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
7c6614f708d956d6d37937dc726757ec5c6fd6d3: Bug 1414084 - Part 13 - Cache PageActions. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 26 Feb 2018 21:50:50 +0100 - rev 791870
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
3225ad07745ca350a5ed24374eb4b8226af22d1d: 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 791869
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +0000
Bug 1414084 - Part 12 - Add some tests for the processing of Menu messages. r?grisha MozReview-Commit-ID: D8Aujo1PgIk
9eebe3e322ff95f581c73fa183308c3cefabddc9: 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 791868
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
89a0da4a53c33aa5e3442edf709052435fb3cada: 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 791867
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
2a8b7a6357cb992bdf1758fe8e52f6ec3b50315f: 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 791866
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
b4f62626aef328c99265012592da57b6d985dbfc: 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 791865
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
4844ff36a244459d32ee2e05750c7b2c5481e2bd: 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 791864
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
214c7be923a5b4e3bd8b33456c7bcc795159cec3: 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 791863
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
b7512074a8d5833f83bb9f1553dccc0e6b1c2634: 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 791862
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
110143ef601f8eaa965ced32b2b7bdb423dc68f9: 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 791861
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
4d7e1c246a02c727a5c9eaff1663e1b9ea96b5e9: 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 791860
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +0000
Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r?grisha MozReview-Commit-ID: 7nEhAUxOIsW
e55e4aa61c1402ecccec7dbf1f0cdfdc6d1cb48b: 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 791859
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
5211c82821f2526b30d48595c5afe444cbe6e402: 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 791858
Push 108906 by mozilla@buttercookie.de at Sun, 06 May 2018 11:18:01 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip