searching for reviewer(ahunt)
ff75ef015293c18eb00f34b0df278c36f292bf94: Bug 1374574 - Remove the FlyWeb system add-on from Fennec. r=ahunt,sebastian
Johann Hofmann <jhofmann@mozilla.com> - Wed, 22 Nov 2017 14:49:35 +0100 - rev 393878
Push 97751 by nbeleuzu@mozilla.com at Tue, 28 Nov 2017 10:08:51 +0000
Bug 1374574 - Remove the FlyWeb system add-on from Fennec. r=ahunt,sebastian MozReview-Commit-ID: AyYD4HedXFv
9baa6614a0bacb00fce0810203a25a67c0357294: Bug 1367851 - Use ComponentCallbacks to listen for low memory notifications. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 25 May 2017 21:22:24 +0200 - rev 361392
Push 90850 by ryanvm@gmail.com at Wed, 31 May 2017 00:47:26 +0000
Bug 1367851 - Use ComponentCallbacks to listen for low memory notifications. r=ahunt At the moment, we forward these from GeckoActivity, which means that they won't work if no GeckoActivity-based activity is active (can happen within our settings for example). As of API14, we can now register an app-wide ComponentCallbacks(2) class, allowing us to easily receive low memory notifications no matter which activity is currently alive. MozReview-Commit-ID: 5GjSjsTKxAD
c2692d96a53e462c01c882810712e0b2afeba378: Bug 1365582 - Stop MediaControlService on task removal; r=ahunt
Jim Chen <nchen@mozilla.com> - Mon, 22 May 2017 17:27:13 -0400 - rev 359977
Push 90556 by nchen@mozilla.com at Mon, 22 May 2017 21:27:33 +0000
Bug 1365582 - Stop MediaControlService on task removal; r=ahunt Stop the media control service when our task is removed, so that the service doesn't block Android from killing our process. MozReview-Commit-ID: 5FfXghJ7XTF
ce2315224c0f8b64740b5334a2616aebaed6c32a: Bug 1329128 - Part 2: Implement create bookmark folder page. r=ahunt,Grisha
Jing-wei Wu <topwu.tw@gmail.com> - Fri, 05 May 2017 00:56:55 +0800 - rev 357491
Push 90127 by cbook@mozilla.com at Wed, 10 May 2017 13:31:57 +0000
Bug 1329128 - Part 2: Implement create bookmark folder page. r=ahunt,Grisha MozReview-Commit-ID: JtSklBDUq7L
caefd3a1d7b7bf174d9a0a7ab6874cda158b2b2b: Bug 1357579 - Correctly copy the sparse Boolean array when clearing Site Settings. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 21 Apr 2017 22:53:19 +0200 - rev 355046
Push 89621 by kwierso@gmail.com at Thu, 27 Apr 2017 00:35:37 +0000
Bug 1357579 - Correctly copy the sparse Boolean array when clearing Site Settings. r=ahunt The checked items are stored in a *sparse* Boolean array, which we want to transform into an array (list) of the checked indices for transmission to Gecko. The current approach doesn't do this correctly, as it iterates over all (sparse and non-sparse) items, but uses SparseBooleanArray.size() (which only counts non-sparse items) as its iteration limit. This means that we only copy the checked state of the first n items, where n is the total count of checked items. For correctly iterating over the array to retrieve all indices that are true, we'd either have to use the largest available key (if we'd want to iterate over everything, including the sparse indices), or else use the approach chosen in this patch, namely using valueAt/keyAt in order to iterate over the internal array that's storing the values for all non-sparse indices. MozReview-Commit-ID: FRGI4Rr0uCb
3f259b3ca03517dd82d7b7a278f1a40a63c53e57: Bug 1358089 - [RTL] Separate xml drawable into v17 folder, r=ahunt
maliu <max@mxli.us> - Mon, 24 Apr 2017 01:16:11 +0800 - rev 355038
Push 89621 by kwierso@gmail.com at Thu, 27 Apr 2017 00:35:37 +0000
Bug 1358089 - [RTL] Separate xml drawable into v17 folder, r=ahunt MozReview-Commit-ID: LaOwxXwhsHA
0cbed2ce192a796646ed92ad4ad91fa3847ea95e: Bug 1232439 - Part 4: Adjust bookmark list UI layout. r=ahunt
Jing-wei Wu <topwu.tw@gmail.com> - Thu, 06 Apr 2017 11:44:20 +0800 - rev 354253
Push 89435 by cbook@mozilla.com at Fri, 21 Apr 2017 09:49:54 +0000
Bug 1232439 - Part 4: Adjust bookmark list UI layout. r=ahunt MozReview-Commit-ID: 5s74hg5daC5
5a0b0722bb130a9fc1c696ae0f538725eebe3843: Bug 1232439 - Part 3: Implement full-page bookmark edit dialog. r=ahunt,Grisha
Jing-wei Wu <topwu.tw@gmail.com> - Thu, 20 Apr 2017 09:04:28 +0800 - rev 354252
Push 89435 by cbook@mozilla.com at Fri, 21 Apr 2017 09:49:54 +0000
Bug 1232439 - Part 3: Implement full-page bookmark edit dialog. r=ahunt,Grisha MozReview-Commit-ID: 8wB9CEptVeu
eec3bab31260bf8cdb5f6937f19bd053811ba0b5: Bug 1353055 - Strip 'vars' debugging information when building Fennec --with-gradle. r=ahunt
Nick Alexander <nalexander@mozilla.com> - Mon, 03 Apr 2017 13:41:11 -0700 - rev 351253
Push 88836 by cbook@mozilla.com at Wed, 05 Apr 2017 12:50:47 +0000
Bug 1353055 - Strip 'vars' debugging information when building Fennec --with-gradle. r=ahunt To observe the difference, use `javap -l`. For example, for automationRelease and automationDebug built with `./mach gradle clean app:assembleAutomationRelease app:assembleAutomationDebug`, I see locally: $ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/release/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class Compiled from "ActivityStreamContextMenu.java" class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> { final android.view.MenuItem val$bookmarkItem; final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0; org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem); LineNumberTable: line 103: 0 <snip> } $ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/debug/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class Compiled from "ActivityStreamContextMenu.java" class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> { final android.view.MenuItem val$bookmarkItem; final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0; org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem); LineNumberTable: line 103: 0 LocalVariableTable: Start Length Slot Name Signature 0 16 0 this Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu$1; 0 16 1 this$0 Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu; 0 16 2 x0 Landroid/os/Handler; <snip> } MozReview-Commit-ID: 3HmiGkHhowQ
80934b6371657e53b11300c079750a8b4004fb68: Bug 1343603 - Part 2 - Test that clearing history clears the cached session store data, too. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 02 Mar 2017 20:19:58 +0100 - rev 346245
Push 87766 by cbook@mozilla.com at Tue, 07 Mar 2017 14:18:49 +0000
Bug 1343603 - Part 2 - Test that clearing history clears the cached session store data, too. r=ahunt MozReview-Commit-ID: 3YhHnmnkgCS
4d31fb49a84451bba01712d7a140bda0a5eb281d: Bug 1343603 - Part 1 - Immediately clear cached session store history data when clearing history. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 02 Mar 2017 20:29:52 +0100 - rev 346244
Push 87766 by cbook@mozilla.com at Tue, 07 Mar 2017 14:18:49 +0000
Bug 1343603 - Part 1 - Immediately clear cached session store history data when clearing history. r=ahunt The session store keeps a serialised copy of a tab's session history around so that the gathering of the data (which can be somewhat expensive) can be decoupled from writing it to disk. When the user clears Firefox's history, we therefore need to discard this data as well (except for the currently open entry), so it doesn't stick around until the next time some navigation/history change occurs in that tab. Otherwise, if Firefox or just the tab is closed before the purged state has been re-collected by the session store, the supposedly purged session history will resurface when the tab is restored again. Bug 1337940 means that we'll now catch the history notifications caused by the session history being purged, however - we still need to handle zombified tabs separately, since as far as the rest of Gecko is concerned, those simply consist of a plain "about:blank" browser with the true state being stashed away in the session store data, so the purging of the live session history data won't have any real effect - the history purging on the tab happens after the session store receives the "browser:purge-session-history" notification, meaning that these changes received through the regular history notifications won't get written to disk immediately Therefore we now explicitly purge the session history data of all tabs in our notification handler, so this state can then immediately be saved to disk. MozReview-Commit-ID: KkR0Tif9BBk
6dee9c5fcc9f8271aed52426d229c5cf2aaa8cde: Bug 1343174 - Part 3 - Test that selectOrAddTab() finds zombified tabs as well. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 28 Feb 2017 20:55:29 +0100 - rev 346243
Push 87766 by cbook@mozilla.com at Tue, 07 Mar 2017 14:18:49 +0000
Bug 1343174 - Part 3 - Test that selectOrAddTab() finds zombified tabs as well. r=ahunt MozReview-Commit-ID: AXeAgRltRP1
8c914488df8c683bd823b732850fed600f7affc7: Bug 1343174 - Part 2 - Rewrite test_selectoraddtab to track tabs instead of browsers. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 28 Feb 2017 20:44:03 +0100 - rev 346242
Push 87766 by cbook@mozilla.com at Tue, 07 Mar 2017 14:18:49 +0000
Bug 1343174 - Part 2 - Rewrite test_selectoraddtab to track tabs instead of browsers. r=ahunt It's easy to get a tab's browser, but going the other way round requires always calling getTabForBrowser(), which then additionally has to search each open tab in turn to find the tab with the matching browser. Also, the browser won't survive tab zombification, so for Part 3 we'll have to start keeping a reference to the tab object anyway. MozReview-Commit-ID: B2aC7vB0cuj
adc6bebaff1d64fcdded2fb562c5cc0d804ba929: Bug 1343174 - Part 1 - When looking for tabs with the same URL, fall back to the session store data for zombie tabs. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 28 Feb 2017 21:09:39 +0100 - rev 346241
Push 87766 by cbook@mozilla.com at Tue, 07 Mar 2017 14:18:49 +0000
Bug 1343174 - Part 1 - When looking for tabs with the same URL, fall back to the session store data for zombie tabs. r=ahunt Delay-loaded tabs all have browsers pointing to about:blank, so there's not much sense in querying browser.currentURI for them. Instead we read their session data to determine the correct URL, which allows selectOrAddTab to successfully detect duplicate tabs even when they are zombified. MozReview-Commit-ID: JZ179Y85Ehe
a600cecf698c94d6ef63e56b3cea90bc33eab48d: Bug 1342329 - Only link the "default browser" setting to the default apps screen. r=ahunt
Sebastian Kaspari <s.kaspari@gmail.com> - Fri, 03 Mar 2017 11:12:48 +0100 - rev 345852
Push 87682 by kwierso@gmail.com at Sat, 04 Mar 2017 01:29:33 +0000
Bug 1342329 - Only link the "default browser" setting to the default apps screen. r=ahunt MozReview-Commit-ID: I7mrsbXGng1
65317946fe00a94ad3ace74581223d79d73858b3: Bug 1342820 - Reset navigation button state when clearing history. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 01 Mar 2017 21:08:11 +0100 - rev 345583
Push 87610 by cbook@mozilla.com at Thu, 02 Mar 2017 13:06:52 +0000
Bug 1342820 - Reset navigation button state when clearing history. r=ahunt Clearing history purges a tab's session history as well. Normally, we only update the navigation button state in the UI for a location change, so now we need to start listening for the appropriate message as well. BrowserApp has already registered a background thread listener for "Sanitize:ClearHistory" - since this can be called during shutdown as well and their listener is more important (clearing the history DB), we defer to them and redispatch to the UI thread ourselves, so BrowserApp doesn't have to do this during shutdown. MozReview-Commit-ID: C83mk6Z56Oq
0b8279c5d55d1e5e57b5dc016520b1d10c4aabb4: Bug 1342354 - Add pref pref on/off switch for new bookmark features. r=ahunt
Nevin Chen <cnevinchen@gmail.com> - Fri, 24 Feb 2017 18:05:10 +0800 - rev 345572
Push 87610 by cbook@mozilla.com at Thu, 02 Mar 2017 13:06:52 +0000
Bug 1342354 - Add pref pref on/off switch for new bookmark features. r=ahunt MozReview-Commit-ID: 1Rz7rAao5Is
6fa30faf379173a45cda1c400a15e4849b94013a: Bug 1337940 - Part 2 - Make session store form data test work again. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 13 Feb 2017 22:16:36 +0100 - rev 345127
Push 87509 by cbook@mozilla.com at Tue, 28 Feb 2017 12:03:17 +0000
Bug 1337940 - Part 2 - Make session store form data test work again. r=ahunt Collecting data for history changes causes an additional session store data update for that tab when navigating back, which needs to be accounted for in this test. Therefore we now also wait for DOMTitleChanged before assuming that the tab has navigated to its intended location. MozReview-Commit-ID: FDNQednXPWh
4285ead0e57a8372d81dd76cf5a4182c3bd3e1fb: Bug 1337940 - Part 1 - Capture session store tab data on history listener notifications. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 11 Feb 2017 21:07:29 +0100 - rev 345126
Push 87509 by cbook@mozilla.com at Tue, 28 Feb 2017 12:03:17 +0000
Bug 1337940 - Part 1 - Capture session store tab data on history listener notifications. r=ahunt So far we've simply used DOMTitleChanged as a proxy for navigation, since it's the earliest opportunity at which we have all necessary data for a new history entry (session history itself as well as tab URL and *title*) available. However it turns out that this is not 100 % reliable, since some pages might e.g. implement their navigation in JS using the history API, which won't necessarily trigger any DOMTitleChanged events. In those case we'd fail to update the tab's session history in the session store unless the user eventually navigated to someplace else that actually triggers a title change event again - if the browser was closed before that, we'd fail to properly restore the user's state. To fix this, we take a similar approach as the desktop session store and collect a tab's history data again when receiving any history change notification for that tab. Because the OnHistory... notifications are mostly cancellable, the session history hasn't been actually updated yet at the point the history listener is being called. We therefore can't synchronously call onTabLoad() from within our history change notification handler and have to schedule an async timeout instead so as to give the session history a chance to complete updating its state. MozReview-Commit-ID: LgHer940QwT
577f20b0aa205169c779b340e8d73cff2cb791cd: Bug 1339737 - Don't set the bookmarks panel scroll position again if the same loader has been reloaded. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 15 Feb 2017 21:48:29 +0100 - rev 344131
Push 87277 by kwierso@gmail.com at Wed, 22 Feb 2017 01:41:20 +0000
Bug 1339737 - Don't set the bookmarks panel scroll position again if the same loader has been reloaded. r=ahunt Changes in the BrowserDB, e.g. because of sync or when opening a link (in a new tab) will trigger the BookmarksLoader's onContentChanged() method, which will trigger a new load reusing the current loader. This means that currently, the code for setting the scroll position in onLoadFinished() gets to run again in that case. We only want to set the scroll position when the user has navigated to a different folder. Folder navigation will always create a fresh loader, therefore we now keep track whether we've already seen a particular loader in onLoadFinished() and only set the scroll position if we're encountering this particular BookmarksLoader instance for the first time. MozReview-Commit-ID: Ln8yeUEoEfr
dd8c7da15822a815cf7072e1b19a01eeba3cf1af: Bug 1337940 - Part 2 - Make session store form data test work again. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 13 Feb 2017 22:16:36 +0100 - rev 344129
Push 87277 by kwierso@gmail.com at Wed, 22 Feb 2017 01:41:20 +0000
Bug 1337940 - Part 2 - Make session store form data test work again. r=ahunt Collecting data for history changes causes an additional session store data update for that tab when navigating back, which needs to be accounted for in this test. Therefore we now also wait for DOMTitleChanged before assuming that the tab has navigated to its intended location. MozReview-Commit-ID: FDNQednXPWh
0172497c1024e8ed758e6aea7bb5d87ca8aec6e5: Bug 1337940 - Part 1 - Capture session store tab data on history listener notifications. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 11 Feb 2017 21:07:29 +0100 - rev 344128
Push 87277 by kwierso@gmail.com at Wed, 22 Feb 2017 01:41:20 +0000
Bug 1337940 - Part 1 - Capture session store tab data on history listener notifications. r=ahunt So far we've simply used DOMTitleChanged as a proxy for navigation, since it's the earliest opportunity at which we have all necessary data for a new history entry (session history itself as well as tab URL and *title*) available. However it turns out that this is not 100 % reliable, since some pages might e.g. implement their navigation in JS using the history API, which won't necessarily trigger any DOMTitleChanged events. In those case we'd fail to update the tab's session history in the session store unless the user eventually navigated to someplace else that actually triggers a title change event again - if the browser was closed before that, we'd fail to properly restore the user's state. To fix this, we take a similar approach as the desktop session store and collect a tab's history data again when receiving any history change notification for that tab. Because the OnHistory... notifications are mostly cancellable, the session history hasn't been actually updated yet at the point the history listener is being called. We therefore can't synchronously call onTabLoad() from within our history change notification handler and have to schedule an async timeout instead so as to give the session history a chance to complete updating its state. MozReview-Commit-ID: LgHer940QwT
fd05b1c1758c4bcea23ee3bb8b0dfc512d58e189: Bug 1269210 - Part 2 - Notify the UI to update the button state on subframe navigation. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 11 Feb 2017 20:32:32 +0100 - rev 342654
Push 86923 by kwierso@gmail.com at Tue, 14 Feb 2017 01:07:39 +0000
Bug 1269210 - Part 2 - Notify the UI to update the button state on subframe navigation. r=ahunt Even if we do the rest of our location change processing only for top level location changes, we still need to update the state of the back and forward buttons even on subframe navigation, so they can become enabled/disabled as necessary. MozReview-Commit-ID: 2wuFZMKtTfj
391c08abb7107b7a77cfd183bb93b84d41570a0f: Bug 1269210 - Part 1 - Remove unused variables from location change message and Java tab object. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 11 Feb 2017 20:13:00 +0100 - rev 342653
Push 86923 by kwierso@gmail.com at Tue, 14 Feb 2017 01:07:39 +0000
Bug 1269210 - Part 1 - Remove unused variables from location change message and Java tab object. r=ahunt We used to need these for the back button long press history menu, but now we no longer do. MozReview-Commit-ID: LAZYffLODN3
406244d181ce2ee4a58868342ae80ea2282814c2: Bug 1338088 - Capture the scroll position for DOMTitleChanged events after the initial page load sequence. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 11 Feb 2017 15:36:17 +0100 - rev 342455
Push 86869 by philringnalda@gmail.com at Sun, 12 Feb 2017 23:33:45 +0000
Bug 1338088 - Capture the scroll position for DOMTitleChanged events after the initial page load sequence. r=ahunt onTabLoad() means we've potentially navigated to a new page, in which case any auxiliary tab data we keep around for the currently loaded page only (form input data, scroll position) would be invalidated and shouldn't be preserved. Since onTabLoad() can however also be triggered if e.g. just the tab title changed (an additional DOMTitleChanged event), we shouldn't throw away the old data without replacing it with the current state, though. We already do this for the form input data - we need to do it for the scroll position as well. MozReview-Commit-ID: HG7g6L7htDG
af979611f4d15604b3469bd3b377570dd9f08446: Bug 1252960 - Rename UrlMetadata* table to UrlImageData* r=ahunt
Tushar Saini (:shatur) <tushar.saini1285@gmail.com> - Thu, 02 Feb 2017 22:05:17 +0530 - rev 341307
Push 86684 by cbook@mozilla.com at Wed, 08 Feb 2017 10:31:03 +0000
Bug 1252960 - Rename UrlMetadata* table to UrlImageData* r=ahunt MozReview-Commit-ID: 2TNcctxAbRc
7038e10280b2905704687ea6d74020c6c437e114: Bug 1252960 - Rename UrlMetadata* table to UrlImageData* r=ahunt
Tushar Saini (:shatur) <tushar.saini1285@gmail.com> - Thu, 02 Feb 2017 22:05:17 +0530 - rev 341296
Push 86684 by cbook@mozilla.com at Wed, 08 Feb 2017 10:31:03 +0000
Bug 1252960 - Rename UrlMetadata* table to UrlImageData* r=ahunt MozReview-Commit-ID: 2TNcctxAbRc
760e78724db96aed26c50441bb8464e5f6f84e32: Bug 1148797 - Don't offer "Undo close tab" for empty tabs with no session history. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 30 Jan 2017 22:40:58 +0100 - rev 341234
Push 86667 by kwierso@gmail.com at Wed, 08 Feb 2017 00:55:58 +0000
Bug 1148797 - Don't offer "Undo close tab" for empty tabs with no session history. r=ahunt MozReview-Commit-ID: CsYgUDrCmUQ
8ff3ef5e885add7d13f43ee2d4b346fc7f3dff34: Bug 1332955 - Consider restore data( for bookmark parent stack) when reloading home panels. r=ahunt
Nevin Chen <cnevinchen@gmail.com> - Wed, 25 Jan 2017 12:10:55 +0800 - rev 341094
Push 86634 by cbook@mozilla.com at Tue, 07 Feb 2017 13:14:58 +0000
Bug 1332955 - Consider restore data( for bookmark parent stack) when reloading home panels. r=ahunt MozReview-Commit-ID: 7m6HOnfPLK3
26b85661155e7db0380a1551c6a21bc905f673b6: Bug 1318667 - Do not use palette library on x86 devices (Use BitmapUtils.getDominantColor()). r=ahunt
Sebastian Kaspari <s.kaspari@gmail.com> - Fri, 03 Feb 2017 18:42:36 +0100 - rev 332502
Push 86548 by kwierso@gmail.com at Sat, 04 Feb 2017 01:35:21 +0000
Bug 1318667 - Do not use palette library on x86 devices (Use BitmapUtils.getDominantColor()). r=ahunt Our version of the palette support library crashes for certain icons on x86 systems. MozReview-Commit-ID: E6eEyFXd4uK
e96ce1680238b4e607fafb5c6072f40a8183d434: Bug 1318544 - Fix TestDownloadAction unit test bustage. r=ahunt
Sebastian Kaspari <s.kaspari@gmail.com> - Tue, 31 Jan 2017 20:43:56 +0100 - rev 332286
Push 86501 by kwierso@gmail.com at Fri, 03 Feb 2017 00:45:15 +0000
Bug 1318544 - Fix TestDownloadAction unit test bustage. r=ahunt The return value of isKnownContent() now depends on whether we exclude this type of content or not. This patch updates the test to reflect that. MozReview-Commit-ID: F4KAVdv2l1X
5e899d7711f6194866ae2e1aa18ab9b0de785d92: Bug 1335355 - Switchboard: Ignore empty matchers in experiments configuration. r=ahunt
Sebastian Kaspari <s.kaspari@gmail.com> - Tue, 31 Jan 2017 14:26:01 +0100 - rev 332094
Push 86449 by kwierso@gmail.com at Thu, 02 Feb 2017 00:31:29 +0000
Bug 1335355 - Switchboard: Ignore empty matchers in experiments configuration. r=ahunt MozReview-Commit-ID: 10T90TjJlGY
01aad8181f5d02e797b24d0b46ceeb727e762f12: Bug 1334562 - DLC: Start study action from BrowserApp.onCreate() and never in automation. r=ahunt
Sebastian Kaspari <s.kaspari@gmail.com> - Mon, 30 Jan 2017 17:41:38 +0100 - rev 331812
Push 86361 by cbook@mozilla.com at Tue, 31 Jan 2017 14:58:10 +0000
Bug 1334562 - DLC: Start study action from BrowserApp.onCreate() and never in automation. r=ahunt Previously we started the DLC service from GeckoApplication. The reason for that was that we wanted to download content like fonts as early as possible so that they are available the next time we display a website. However we do not know whether we are running in automation until the BrowserApp activity is launched. This patch will start the service from BrowserApp.onCreate() now if we are not running in automation. MozReview-Commit-ID: C3Ob6S3yve4
185b45c00b7b63dab0bf3f33d0791dbbd9b1f5bc: Bug 1062859 - Part 1 - Restore scroll position when going back through bookmark folders. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 22 Jan 2017 22:02:35 +0100 - rev 331778
Push 86361 by cbook@mozilla.com at Tue, 31 Jan 2017 14:58:10 +0000
Bug 1062859 - Part 1 - Restore scroll position when going back through bookmark folders. r=ahunt When going down one folder level, we store the current scroll position of the list view and then scroll to the top of the list, so that we always show a child folder starting from the beginning. When navigating back up to its parent, we then restore the previously stored scroll position. MozReview-Commit-ID: 9C2RMXrlUm1
6545d3df6dcfcbf22de00928ecb88765bb27d83e: Bug 1062859 - Part 0 - Bookmarks panel cleanups. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 23 Jan 2017 19:23:55 +0100 - rev 331777
Push 86361 by cbook@mozilla.com at Tue, 31 Jan 2017 14:58:10 +0000
Bug 1062859 - Part 0 - Bookmarks panel cleanups. r=ahunt Fix up javadoc so it matches the actual function parameter and remove unneeded imports. MozReview-Commit-ID: I91NuqLlpL1
2bd13e9c2a0163268ddd2cbeb60cd0ea3bf55c66: Bug 1333046 - Part 2 - Move zombification function into the tab object. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 19 Jan 2017 21:45:03 +0100 - rev 331255
Push 86212 by kwierso@gmail.com at Fri, 27 Jan 2017 00:32:32 +0000
Bug 1333046 - Part 2 - Move zombification function into the tab object. r=ahunt A tab object should know how to zombify itself instead of having to rely on the MemoryObserver. This also simplifies the situation for anybody else who wants to call this function since it is no longer necessary to figure out how to load the MemoryObserver for this. MozReview-Commit-ID: 5IX114QUjBT
11ba6139302ef4dc1f98035de7ede34fe6da19fc: Bug 1333046 - Part 1 - Expose a method to restore delay-loaded tabs via the tab object. r=ahunt
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 25 Jan 2017 21:33:33 +0100 - rev 331254
Push 86212 by kwierso@gmail.com at Fri, 27 Jan 2017 00:32:32 +0000
Bug 1333046 - Part 1 - Expose a method to restore delay-loaded tabs via the tab object. r=ahunt Actors outside of the session store shouldn't have to poke around within the session store's data structure and end up reimplementing parts of the session store code (and cause data loss if the implementation is incomplete) in order to restore delay loaded zombie tabs. Therefore, we simply expose a method for this via BrowserApp's tab object. To simplify handling and make the method a little more fool-proof for external callers, the check whether the tab is actually zombified is moved into the restoreZombieTab() function. Later on, we can also hook up this method to the appropriate web extension API (see bug 1322485). MozReview-Commit-ID: 85lnbCpMcP3
f560f0eef6be10a2e86ba9e5bcbfe6ad911d1969: Bug 1311555 - Pre: remove unused imports r=ahunt
Andrzej Hunt <ahunt@mozilla.com> - Wed, 18 Jan 2017 12:18:06 +0100 - rev 330306
Push 85939 by cbook@mozilla.com at Fri, 20 Jan 2017 14:42:14 +0000
Bug 1311555 - Pre: remove unused imports r=ahunt MozReview-Commit-ID: 6Xk7Z01m41A
57ccc83a450f5b10fcc65452f15bd54cc547857b: Bug 1311555 - Pre: remove unused imports r=ahunt
Andrzej Hunt <ahunt@mozilla.com> - Wed, 18 Jan 2017 12:18:06 +0100 - rev 330215
Push 85914 by philringnalda@gmail.com at Fri, 20 Jan 2017 06:12:58 +0000
Bug 1311555 - Pre: remove unused imports r=ahunt MozReview-Commit-ID: 6Xk7Z01m41A
deb2014e1eb50438f9390a0b5e378d86f3e6b18e: Bug 1330280 - Refactor testActivityStreamContextMenu to use new Highlight/TopSite model classes. r=ahunt,Grisha
Sebastian Kaspari <s.kaspari@gmail.com> - Thu, 12 Jan 2017 17:30:20 +0100 - rev 330096
Push 85897 by cbook@mozilla.com at Thu, 19 Jan 2017 15:35:41 +0000
Bug 1330280 - Refactor testActivityStreamContextMenu to use new Highlight/TopSite model classes. r=ahunt,Grisha MozReview-Commit-ID: 8pwUVQHwPu6
4e763552b6cf1e3401d1da1e70409e8f3753d944: Bug 1029646 - Update layout direction of configuration and DecorView, r=ahunt
maliu <max@mxli.us> - Tue, 03 Jan 2017 15:14:59 +0800 - rev 329572
Push 85733 by cbook@mozilla.com at Mon, 16 Jan 2017 15:44:30 +0000
Bug 1029646 - Update layout direction of configuration and DecorView, r=ahunt MozReview-Commit-ID: FiDwoX45yV9
64767e9197dffe57e1f5f10839048cf7fb5e11b8: Bug 1321633 - Apply gradient based on text direction with first strong strategy, r=ahunt
maliu <max@mxli.us> - Thu, 29 Dec 2016 17:24:32 +0800 - rev 329564
Push 85733 by cbook@mozilla.com at Mon, 16 Jan 2017 15:44:30 +0000
Bug 1321633 - Apply gradient based on text direction with first strong strategy, r=ahunt MozReview-Commit-ID: 5GMlUcp290f
651fbecc80af7f31d8dfb5769482034cbef4d2a3: Bug 1325488 - Deduplicate subdomain removal in IconGenerator. r=ahunt
Brian Chen <brianchen0810@hotmail.com> - Fri, 23 Dec 2016 17:35:00 -0500 - rev 329488
Push 85714 by ryanvm@gmail.com at Sun, 15 Jan 2017 20:03:59 +0000
Bug 1325488 - Deduplicate subdomain removal in IconGenerator. r=ahunt
8c6d9f66b68a4a35b16460720d3ffea9bf2f1bfa: Bug 1323763 - Revert setAutomirrored solution and provide drawable in ldrtl folder, r=ahunt
maliu <max@mxli.us> - Fri, 16 Dec 2016 18:21:58 +0800 - rev 327358
Push 85168 by philringnalda@gmail.com at Wed, 28 Dec 2016 04:38:14 +0000
Bug 1323763 - Revert setAutomirrored solution and provide drawable in ldrtl folder, r=ahunt MozReview-Commit-ID: JwHTNbQ1HcN
358981f2f69e41884d660de7bdbfbbc64c7afb20: Bug 1320798 - Re-order context menu items for Activity Stream r=ahunt
Grisha Kruglov <gkruglov@mozilla.com> - Wed, 21 Dec 2016 14:30:50 -0800 - rev 327074
Push 85091 by kwierso@gmail.com at Fri, 23 Dec 2016 02:44:56 +0000
Bug 1320798 - Re-order context menu items for Activity Stream r=ahunt MozReview-Commit-ID: Ldt0H5XQxsz
03bd43cec49fa6fc5c86dd579f629fc2dde5060a: Bug 1323952 - Preferences: Set default 'compact tabs' value based on experiment. r=ahunt,nechen
Sebastian Kaspari <s.kaspari@gmail.com> - Tue, 20 Dec 2016 19:28:08 +0100 - rev 326915
Push 85073 by cbook@mozilla.com at Thu, 22 Dec 2016 15:25:55 +0000
Bug 1323952 - Preferences: Set default 'compact tabs' value based on experiment. r=ahunt,nechen MozReview-Commit-ID: EbE1Lrk90bc
fbb8ff8e9ad9dc2e2fb6e304042bf7613903cb1f: Bug 1323952 - Tabs panel: Update default based on compact tabs experiment. r=ahunt,nechen
Sebastian Kaspari <s.kaspari@gmail.com> - Tue, 20 Dec 2016 15:43:12 +0100 - rev 326914
Push 85073 by cbook@mozilla.com at Thu, 22 Dec 2016 15:25:55 +0000
Bug 1323952 - Tabs panel: Update default based on compact tabs experiment. r=ahunt,nechen MozReview-Commit-ID: GTJ3YMLvHup
c1224e1c719805cc5ce90c25378bdc76739bcbe7: Bug 1323952 - Add compact tabs experiment. r=ahunt,nechen
Sebastian Kaspari <s.kaspari@gmail.com> - Tue, 20 Dec 2016 15:41:42 +0100 - rev 326913
Push 85073 by cbook@mozilla.com at Thu, 22 Dec 2016 15:25:55 +0000
Bug 1323952 - Add compact tabs experiment. r=ahunt,nechen MozReview-Commit-ID: DSoEm62tLRW
a06f80881726c208555b6b14eee52d7f19af7cd2: Bug 1320889 - Tapping the notification for a downloaded file shouldn't open firefox. r=ahunt
Nevin Chen <cnevinchen@gmail.com> - Fri, 16 Dec 2016 16:30:19 +0800 - rev 326582
Push 84987 by kwierso@gmail.com at Tue, 20 Dec 2016 19:48:07 +0000
Bug 1320889 - Tapping the notification for a downloaded file shouldn't open firefox. r=ahunt MozReview-Commit-ID: FzBk0TmVlm0
ef38ce7ce64ddef56fcdf1554106a8008e9d47f8: Bug 1241262 - Use resolveInfo.activityInfo.icon instead of resolveInfo.icon to support SDK 23 and later. r=ahunt
Nevin Chen <cnevinchen@gmail.com> - Thu, 01 Dec 2016 15:56:41 +0800 - rev 326580
Push 84987 by kwierso@gmail.com at Tue, 20 Dec 2016 19:48:07 +0000
Bug 1241262 - Use resolveInfo.activityInfo.icon instead of resolveInfo.icon to support SDK 23 and later. r=ahunt MozReview-Commit-ID: nGV2ElQEO2