searching for reviewer(nechen)
d686b90e9c64c46ce0c49ab83edff387cda40a38: Bug 1438716 - Upgrade Leanplum SDK. r=nechen
Andrei Lazar <andrei.a.lazar@softvision.ro> - Wed, 30 May 2018 17:09:30 +0300 - rev 426736
Push 105308 by cbrindusan@mozilla.com at Mon, 16 Jul 2018 15:50:27 +0000
Bug 1438716 - Upgrade Leanplum SDK. r=nechen Upgraded to version 3.0.2 from official repository while keeping the internal changes. This upgrade encapsulates some major changes as well as bug fixes. MozReview-Commit-ID: DMOEIKnw0nJ
51086f4622b31c4183b7400692ba759d18858f52: Bug 1158979 - Removed StringHelper.get and changed StringHelper.initialize to return the StringHelper instance. r=nechen
sreeise <reeisesean@gmail.com> - Sun, 27 May 2018 02:44:59 -0400 - rev 421789
Push 104125 by aciure@mozilla.com at Thu, 07 Jun 2018 21:57:03 +0000
Bug 1158979 - Removed StringHelper.get and changed StringHelper.initialize to return the StringHelper instance. r=nechen Uses of StringHelper.get are replaced with the StringHelper instance in BaseRobocopTest.java and UITestContext. MozReview-Commit-ID: FfMhdNCX1vC
8acb65ad7377ee946e9f55b2f5ae00e02ed25900: Bug 1444428 - Remove unsafeSetInnerHTML in config.js. r=nechen
Johann Hofmann <jhofmann@mozilla.com> - Fri, 13 Apr 2018 15:12:15 +0200 - rev 413909
Push 102220 by cbrindusan@mozilla.com at Tue, 17 Apr 2018 10:11:08 +0000
Bug 1444428 - Remove unsafeSetInnerHTML in config.js. r=nechen MozReview-Commit-ID: CHyl9FJQ7j9
4f4e8888611f380f8fb4f8bc7cd888aef1bae3df: Bug 1429386 Added missing functionalities from a newer LP SDK version r=nechen
Vlad Baicu <vlad.baicu@softvision.ro> - Thu, 05 Apr 2018 19:09:45 +0300 - rev 412392
Push 101913 by nerli@mozilla.com at Mon, 09 Apr 2018 17:05:11 +0000
Bug 1429386 Added missing functionalities from a newer LP SDK version r=nechen MozReview-Commit-ID: EWGABsN3Diu
0d73894a5fc45ca86b7498a1da0de719516b654e: Bug 1439831 - Enable ESLint rule mozilla/use-services for mobile/android. r=nechen
Mark Banner <standard8@mozilla.com> - Wed, 21 Feb 2018 08:57:28 +0000 - rev 406293
Push 100404 by apavel@mozilla.com at Fri, 02 Mar 2018 16:25:22 +0000
Bug 1439831 - Enable ESLint rule mozilla/use-services for mobile/android. r=nechen MozReview-Commit-ID: 3MuRD78hMuE
6496c32d75a24e7994572785eccedfa2da38cf92: Bug 1439380 - Remove uses of Promise.jsm from mobile/android. r=nechen
Mark Banner <standard8@mozilla.com> - Mon, 19 Feb 2018 15:50:26 +0000 - rev 404508
Push 100027 by shindli@mozilla.com at Tue, 20 Feb 2018 19:15:11 +0000
Bug 1439380 - Remove uses of Promise.jsm from mobile/android. r=nechen MozReview-Commit-ID: KzrWz3K6vva
c8004be7f2a0a5aba884c17f012787347702d09b: Bug 1432619 - Remove DawnHelper. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 23 Jan 2018 22:37:51 +0100 - rev 400968
Push 99272 by apavel@mozilla.com at Fri, 26 Jan 2018 17:52:07 +0000
Bug 1432619 - Remove DawnHelper. r=nechen It was only used in the 55 Nightly and never meant to stay around. MozReview-Commit-ID: JDJr9WC4V5M
7632333fd2edbd08b4419d4462d176f6029e0663: Bug 1419581 - Part 1: Simplify MMA GCM sender IDs logic. r=nechen
Tad <tad@spotco.us> - Fri, 12 Jan 2018 15:03:37 -0800 - rev 400906
Push 99254 by dluca@mozilla.com at Fri, 26 Jan 2018 03:51:01 +0000
Bug 1419581 - Part 1: Simplify MMA GCM sender IDs logic. r=nechen Right now, the MMA glue is built into constants.jar. constants.jar is the home of preprocessed Java code; it's built very early in the build process and intended to be a tiny kernel of shared definitions. The fact that the MMA glue has to live there is just a sad consequence of the non-Gradle build system, which makes dependency injection difficult. Unfortunately, another consequence is that it's not possible to move reference org.mozilla.gecko.{gcm,push} in the MMA glue, because those packages are built after constants.jar. Instead, this patch lifts some of the logic into AppConstants, which is part of constants.jar. We had grown a twisty maze of indirection around the GCM sender IDs and it just wasn't necessary; this just lifts the static pieces up a level and removes a bunch of interface indirection. What surprises me is that asking Google's InstanceId.getToken for a GCM token with a "comma,separated,list" of GCM sender IDs works -- and indeed, has worked since we added the second MMA sender ID. I didn't expect that and can't explain it, but this doesn't change that logic and local testing (both of the existing APKs, and APKs with this modification) looks good. MozReview-Commit-ID: 3hObfAwNlPH *** a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen MozReview-Commit-ID: A4hrk6pVqGW
f8b3e95f18e4082ab8404187508d09eadba8612e: Bug 1419581 - Part 1: Simplify MMA GCM sender IDs logic. r=nechen
Tad <tad@spotco.us> - Fri, 12 Jan 2018 15:03:37 -0800 - rev 400528
Push 99180 by archaeopteryx@coole-files.de at Wed, 24 Jan 2018 12:24:59 +0000
Bug 1419581 - Part 1: Simplify MMA GCM sender IDs logic. r=nechen Right now, the MMA glue is built into constants.jar. constants.jar is the home of preprocessed Java code; it's built very early in the build process and intended to be a tiny kernel of shared definitions. The fact that the MMA glue has to live there is just a sad consequence of the non-Gradle build system, which makes dependency injection difficult. Unfortunately, another consequence is that it's not possible to move reference org.mozilla.gecko.{gcm,push} in the MMA glue, because those packages are built after constants.jar. Instead, this patch lifts some of the logic into AppConstants, which is part of constants.jar. We had grown a twisty maze of indirection around the GCM sender IDs and it just wasn't necessary; this just lifts the static pieces up a level and removes a bunch of interface indirection. What surprises me is that asking Google's InstanceId.getToken for a GCM token with a "comma,separated,list" of GCM sender IDs works -- and indeed, has worked since we added the second MMA sender ID. I didn't expect that and can't explain it, but this doesn't change that logic and local testing (both of the existing APKs, and APKs with this modification) looks good. MozReview-Commit-ID: 3hObfAwNlPH *** a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen MozReview-Commit-ID: A4hrk6pVqGW
f5fe81e72056ad5c024a059570ac09db474894d6: Bug 1389829 - Part 4 - Add simple Robocop test for View Page Source. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 13 Jan 2018 21:10:45 +0100 - rev 400526
Push 99180 by archaeopteryx@coole-files.de at Wed, 24 Jan 2018 12:24:59 +0000
Bug 1389829 - Part 4 - Add simple Robocop test for View Page Source. r=nechen MozReview-Commit-ID: DFC17YSSinx
d9e0b22fd920e4cf5ae82ea5dfaeb005721bfc22: Bug 1389829 - Part 1 - Add "View Page Source" to the Page menu in the UI. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 13 Aug 2017 16:15:26 +0200 - rev 400523
Push 99180 by archaeopteryx@coole-files.de at Wed, 24 Jan 2018 12:24:59 +0000
Bug 1389829 - Part 1 - Add "View Page Source" to the Page menu in the UI. r=nechen The Page menu is disabled when no tab is open, so not doing a null-check on the currently selected tab in the menu click handler is safe. MozReview-Commit-ID: CYKHJ5N1q8I
01cd32e4db46c6af47e7c3d938bb74cc8867e3df: Bug 1414928 - Part 2 - Updating the progress bar once is enough. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 06 Nov 2017 20:36:10 +0100 - rev 400312
Push 99138 by dluca@mozilla.com at Tue, 23 Jan 2018 10:14:28 +0000
Bug 1414928 - Part 2 - Updating the progress bar once is enough. r=nechen We still need to explicitly set the progress when loading stops, so the progress bar animates to completion before updateProgressState hides it, but in all other cases calling just updateProgressState is enough to set the new progress value. MozReview-Commit-ID: 9mQr5s83i9F
f7afc687263c633d98c69ea6b327ae17aad26f87: Bug 1414928 - Part 1 - Rename updateProgressvisibility to make its function clearer. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 13 Jan 2018 13:43:15 +0100 - rev 400311
Push 99138 by dluca@mozilla.com at Tue, 23 Jan 2018 10:14:28 +0000
Bug 1414928 - Part 1 - Rename updateProgressvisibility to make its function clearer. r=nechen MozReview-Commit-ID: 8mLUsJ0tfS3
cb9d29d5f5bd9b4f90f95b384ef5eb9947850922: Bug 1424252 - [2.0] Enable text selection complementary to the HTML or native context menu. r=nechen
Eugen Sawin <esawin@mozilla.com> - Fri, 19 Jan 2018 16:31:15 +0100 - rev 400169
Push 99103 by esawin@mozilla.com at Mon, 22 Jan 2018 14:09:13 +0000
Bug 1424252 - [2.0] Enable text selection complementary to the HTML or native context menu. r=nechen
8f1655752d43af33356d497d559888a967bbf6a0: Bug 1419581 - Part 1: Simplify MMA GCM sender IDs logic. r=nechen
Tad <tad@spotco.us> - Fri, 12 Jan 2018 15:03:37 -0800 - rev 399575
Push 98981 by csabou@mozilla.com at Wed, 17 Jan 2018 09:51:16 +0000
Bug 1419581 - Part 1: Simplify MMA GCM sender IDs logic. r=nechen Right now, the MMA glue is built into constants.jar. constants.jar is the home of preprocessed Java code; it's built very early in the build process and intended to be a tiny kernel of shared definitions. The fact that the MMA glue has to live there is just a sad consequence of the non-Gradle build system, which makes dependency injection difficult. Unfortunately, another consequence is that it's not possible to move reference org.mozilla.gecko.{gcm,push} in the MMA glue, because those packages are built after constants.jar. Instead, this patch lifts some of the logic into AppConstants, which is part of constants.jar. We had grown a twisty maze of indirection around the GCM sender IDs and it just wasn't necessary; this just lifts the static pieces up a level and removes a bunch of interface indirection. What surprises me is that asking Google's InstanceId.getToken for a GCM token with a "comma,separated,list" of GCM sender IDs works -- and indeed, has worked since we added the second MMA sender ID. I didn't expect that and can't explain it, but this doesn't change that logic and local testing (both of the existing APKs, and APKs with this modification) looks good. MozReview-Commit-ID: 3hObfAwNlPH *** a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen MozReview-Commit-ID: A4hrk6pVqGW
93547276fba805541a03a47c99516a61846e0cc5: Bug 1419581 - Part 1: Simplify MMA GCM sender IDs logic. r=nechen
Tad <tad@spotco.us> - Fri, 12 Jan 2018 15:03:37 -0800 - rev 399551
Push 98981 by csabou@mozilla.com at Wed, 17 Jan 2018 09:51:16 +0000
Bug 1419581 - Part 1: Simplify MMA GCM sender IDs logic. r=nechen Right now, the MMA glue is built into constants.jar. constants.jar is the home of preprocessed Java code; it's built very early in the build process and intended to be a tiny kernel of shared definitions. The fact that the MMA glue has to live there is just a sad consequence of the non-Gradle build system, which makes dependency injection difficult. Unfortunately, another consequence is that it's not possible to move reference org.mozilla.gecko.{gcm,push} in the MMA glue, because those packages are built after constants.jar. Instead, this patch lifts some of the logic into AppConstants, which is part of constants.jar. We had grown a twisty maze of indirection around the GCM sender IDs and it just wasn't necessary; this just lifts the static pieces up a level and removes a bunch of interface indirection. What surprises me is that asking Google's InstanceId.getToken for a GCM token with a "comma,separated,list" of GCM sender IDs works -- and indeed, has worked since we added the second MMA sender ID. I didn't expect that and can't explain it, but this doesn't change that logic and local testing (both of the existing APKs, and APKs with this modification) looks good. MozReview-Commit-ID: 3hObfAwNlPH *** a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen MozReview-Commit-ID: A4hrk6pVqGW
f165daa1ddffe1ea8875cf8cc4894943f08d7f84: Bug 1430203 - [1.0] Ignore anchor elements with missing href when determining context menu type. r=nechen
Eugen Sawin <esawin@mozilla.com> - Tue, 16 Jan 2018 16:54:20 +0100 - rev 399415
Push 98952 by esawin@mozilla.com at Tue, 16 Jan 2018 15:55:41 +0000
Bug 1430203 - [1.0] Ignore anchor elements with missing href when determining context menu type. r=nechen
df5c4759691588a85ab2017d3e226fafa417bb68: Bug 1424252 - Remove <menu> support in Fennec. r=nechen
Eugen Sawin <esawin@mozilla.com> - Wed, 10 Jan 2018 10:09:00 -0500 - rev 398743
Push 98818 by aciure@mozilla.com at Thu, 11 Jan 2018 10:09:18 +0000
Bug 1424252 - Remove <menu> support in Fennec. r=nechen
2837beb133208466c90650d4c3fc6b7c9233882c: Bug 1423566 - Hide tabs tray when receiving an Assist App intent. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 05 Jan 2018 17:33:06 +0100 - rev 398244
Push 98705 by btara@mozilla.com at Mon, 08 Jan 2018 22:18:56 +0000
Bug 1423566 - Hide tabs tray when receiving an Assist App intent. r=nechen We're still somewhat undecided on how to exactly handle external intents arriving while the tabs tray is open, however in the case of Assist App intents - opening a new tab in editing mode while the tabs tray remains open causes some weird behaviour (the keyboard appears in front of the tabs tray and no matter which tab is selected on the tabs tray, you first enter editing mode and then always end up in the tab opened by the Assist App intent) - the goal of our Assist App intent handling is to allow the user to enter a search query or an address into the URL bar hence we should hide the tabs tray (if open) when handling such an intent. MozReview-Commit-ID: GpwrscdNjZP
73863c493315ec5b769c4db4c1e07b7382c12862: Bug 1352133 - Handle selected tab not yet existing when exiting BrowserSearch. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 28 Dec 2017 15:29:24 +0100 - rev 397870
Push 98635 by toros@mozilla.com at Fri, 05 Jan 2018 10:04:14 +0000
Bug 1352133 - Handle selected tab not yet existing when exiting BrowserSearch. r=nechen Early during startup there might not be a selected tab yet, so we can't use its data to decide which home panel to show again. Fortunately showHomePager can be called with a null panelId, in which case it will eventually simply fall back to using the default home panel from our settings. MozReview-Commit-ID: GbmozJeYZVb
da52ff7129ad5c91aedc1f81a0a916aece58e361: Bug 1414309 - Tell ToolbarEditLayout's title background about private mode changes. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 22 Dec 2017 19:46:20 +0100 - rev 397869
Push 98635 by toros@mozilla.com at Fri, 05 Jan 2018 10:04:14 +0000
Bug 1414309 - Tell ToolbarEditLayout's title background about private mode changes. r=nechen The background is enabled when using a theme to increase readability of the URL, but disabled in private mode, because we don't show the theme while in private mode. However for the latter feature to work, the respective layout needs to be told about the private mode state of the toolbar in the first place. We did this for the ToolbarDisplayLayout, but had forgotten the ToolbarEditLayout. MozReview-Commit-ID: 3GAesHvwDEX
b5679bcdadf8f9538b4e431df0031d601378d1a7: Bug 1352133 - Handle selected tab not yet existing when exiting BrowserSearch. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 28 Dec 2017 15:29:24 +0100 - rev 397796
Push 98618 by apavel@mozilla.com at Thu, 04 Jan 2018 21:34:32 +0000
Bug 1352133 - Handle selected tab not yet existing when exiting BrowserSearch. r=nechen Early during startup there might not be a selected tab yet, so we can't use its data to decide which home panel to show again. Fortunately showHomePager can be called with a null panelId, in which case it will eventually simply fall back to using the default home panel from our settings. MozReview-Commit-ID: GbmozJeYZVb
bfdc585f72b3a38e62272a963b2d17ac94f4f439: Bug 1414309 - Tell ToolbarEditLayout's title background about private mode changes. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 22 Dec 2017 19:46:20 +0100 - rev 397795
Push 98618 by apavel@mozilla.com at Thu, 04 Jan 2018 21:34:32 +0000
Bug 1414309 - Tell ToolbarEditLayout's title background about private mode changes. r=nechen The background is enabled when using a theme to increase readability of the URL, but disabled in private mode, because we don't show the theme while in private mode. However for the latter feature to work, the respective layout needs to be told about the private mode state of the toolbar in the first place. We did this for the ToolbarDisplayLayout, but had forgotten the ToolbarEditLayout. MozReview-Commit-ID: 3GAesHvwDEX
36b69642c15c332a26834289db75c5aaeab1c4d4: Bug 1426864 - Determine private mode via browser toolbar, 2nd edition. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 22 Dec 2017 18:51:11 +0100 - rev 397451
Push 98523 by ncsoregi@mozilla.com at Wed, 27 Dec 2017 09:52:15 +0000
Bug 1426864 - Determine private mode via browser toolbar, 2nd edition. r=nechen Similar to maybeSwitchToTab in bug 1426613, a search might be launched while we don't have a selected tab yet. Therefore we determine private mode state via the browser toolbar instead. MozReview-Commit-ID: 4idUR8v7MCx
90f70240f40956ab6eba75ecb8f985bb92a8ac22: Bug 1426613 - Determine private mode via browser toolbar. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 22 Dec 2017 18:23:03 +0100 - rev 397450
Push 98523 by ncsoregi@mozilla.com at Wed, 27 Dec 2017 09:52:15 +0000
Bug 1426613 - Determine private mode via browser toolbar. r=nechen The currently selected tab might not actually exist immediately after startup, in which case the browser toolbar is a safer bet for determining whether we're in private mode or not. I think the current worst case is when we're - not restoring a previous session, and - need to open some tab queue tabs, and - also need to open some other tab in response to our launch intent in which case we won't have a selected tab in Java until after Gecko is up and running. This in turn can take a while, especially when a fresh copy of libxul.so needs to be extracted after an update/installation/cleared cache/..., which potentially gives the user ample time to click on a search result/Top Sites entry/... that then triggers this crash. MozReview-Commit-ID: FlJZw2aL8OM
d18fcc606dc798240da66644e0420423510138b0: Bug 1425052 - Enable ESLint rule no-undef for as much of mobile/android as possible. r=nechen
Mark Banner <standard8@mozilla.com> - Wed, 13 Dec 2017 10:14:37 -0600 - rev 397424
Push 98521 by aiakab@mozilla.com at Tue, 26 Dec 2017 21:38:01 +0000
Bug 1425052 - Enable ESLint rule no-undef for as much of mobile/android as possible. r=nechen MozReview-Commit-ID: IKqMxBgsKqt
dac40e5e9cff836eacc24fa55c0bd9b408efe3f7: Bug 1424864. Fix some minor issues raised by ESLint when enabling no-undef on mobile/android. r=nechen
Mark Banner <standard8@mozilla.com> - Mon, 11 Dec 2017 19:34:05 +0000 - rev 397423
Push 98521 by aiakab@mozilla.com at Tue, 26 Dec 2017 21:38:01 +0000
Bug 1424864. Fix some minor issues raised by ESLint when enabling no-undef on mobile/android. r=nechen MozReview-Commit-ID: Bd052TWrbBv
a253d4ac1e2b8e2a139f7080dc885a56d05eefa6: Bug 1424523 - Lazify Sanitizer.jsm's imports. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 09 Dec 2017 20:23:56 +0100 - rev 397412
Push 98518 by btara@mozilla.com at Sun, 24 Dec 2017 22:13:08 +0000
Bug 1424523 - Lazify Sanitizer.jsm's imports. r=nechen Even though the Sanitizer itself will be lazy-loaded, most imports are only required for specific data categories. Therefore for users who aren't clearing all data at once, lazy-loading can still be beneficial. MozReview-Commit-ID: CLM1BN0XeJj
92d7837be2dbb28c5648282fb61843c43d2b00bd: Bug 1413739 - Part 2 - Simple test for handling of an ACTION_ASSIST intent. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 03 Dec 2017 21:03:47 +0100 - rev 394954
Push 97987 by nerli@mozilla.com at Tue, 05 Dec 2017 13:52:50 +0000
Bug 1413739 - Part 2 - Simple test for handling of an ACTION_ASSIST intent. r=nechen assertUrl wasn't used before and getUrlEditText().getText() returns a SpannableStringBuilder, so we need to add a toString() conversion there in order to successfully use it. MozReview-Commit-ID: 9BtZWDRstdD
151826976a7d1cc0773017bdbd1eaa8554fc247e: Bug 1413739 - Part 1 - Offer Firefox itself as an Assist App. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 03 Dec 2017 21:16:03 +0100 - rev 394953
Push 97987 by nerli@mozilla.com at Tue, 05 Dec 2017 13:52:50 +0000
Bug 1413739 - Part 1 - Offer Firefox itself as an Assist App. r=nechen The technique for setting our icon is just a straight reimplementation of bug 1210242. Because of the way the new tab might be opened from within a processActionViewIntent Runnable, we can't enter editing mode by simply listening for an ACTION_ASSIST intent from within BrowserApp, as we need to enter editing mode *after* the correct tab has already been opened and selected and BrowserApp doesn't get any hint on when that Runnable might have run. Instead, we introduce a new tab event, so we can trigger editing mode at the right time via the tab itself. MozReview-Commit-ID: 8Bvv5TXyhhI
3176ff271bd7ee01b48faa09d93590e902245975: Bug 1421859 - Remove flat_icon now that it is unused. r=nechen
Ian Moody <moz-ian@perix.co.uk> - Sun, 03 Dec 2017 18:44:53 +0000 - rev 394819
Push 97969 by btara@mozilla.com at Mon, 04 Dec 2017 20:48:53 +0000
Bug 1421859 - Remove flat_icon now that it is unused. r=nechen MozReview-Commit-ID: 7wJ0JL2fBFC
544693ed0c93719f34c144054f17b5e2a99fb5da: Bug 1421859 - Use ic_status_logo instead of flat_icon in MediaControl and TabReceived notifications. r=nechen
Ian Moody <moz-ian@perix.co.uk> - Sun, 03 Dec 2017 18:43:38 +0000 - rev 394818
Push 97969 by btara@mozilla.com at Mon, 04 Dec 2017 20:48:53 +0000
Bug 1421859 - Use ic_status_logo instead of flat_icon in MediaControl and TabReceived notifications. r=nechen ic_status_logo is what all the other notifications use, and flat_icon hasn't been updated to the new photon logo. MozReview-Commit-ID: Luo5ibVmXvk
4facc0b0613e681014475432a4c749351ec07cfe: Bug 1417049 - [1.2] Don't show Add to Home Screen page action for incompatible launchers. r=nechen
Eugen Sawin <esawin@mozilla.com> - Tue, 28 Nov 2017 22:19:02 +0100 - rev 394176
Push 97829 by esawin@mozilla.com at Wed, 29 Nov 2017 16:27:29 +0000
Bug 1417049 - [1.2] Don't show Add to Home Screen page action for incompatible launchers. r=nechen
76bdc9a9451de58725f2f31553d4b22bae3694d1: Bug 1416251 - Remove conditional catch consumers in mobile/android/. r=nechen
Tooru Fujisawa <arai_a@mac.com> - Wed, 29 Nov 2017 19:58:31 +0900 - rev 394160
Push 97819 by arai_a@mac.com at Wed, 29 Nov 2017 11:01:07 +0000
Bug 1416251 - Remove conditional catch consumers in mobile/android/. r=nechen
7a1a46675739ef7b49e7ba78f7e1c2c9d593d0e3: Bug 1352497 - Remove about:healthreport. r=gfritzsche,nechen
Dão Gottwald <dao@mozilla.com> - Tue, 28 Nov 2017 11:38:15 +0100 - rev 394000
Push 97798 by toros@mozilla.com at Wed, 29 Nov 2017 00:40:28 +0000
Bug 1352497 - Remove about:healthreport. r=gfritzsche,nechen MozReview-Commit-ID: 4FQ5aL2XrU5
8862a30b358ede2e233c01e161c94092ca591c51: Bug 1418734 - Remove HashMap from SecurityModeUtil r=nechen
Andrew Gaul <andrew@gaul.org> - Sat, 18 Nov 2017 21:41:20 -0800 - rev 393932
Push 97752 by csabou@mozilla.com at Tue, 28 Nov 2017 10:43:05 +0000
Bug 1418734 - Remove HashMap from SecurityModeUtil r=nechen Replace with enum field. Also hoist getImageLevel into enum and change callers.
be86ccde4f4a90a64b098ce7dce70a3f89f48f72: Bug 1352497 - Remove about:healthreport. r=gfritzsche,nechen
Dão Gottwald <dao@mozilla.com> - Wed, 22 Nov 2017 13:51:08 +0100 - rev 393585
Push 97685 by aciure@mozilla.com at Fri, 24 Nov 2017 22:25:57 +0000
Bug 1352497 - Remove about:healthreport. r=gfritzsche,nechen MozReview-Commit-ID: 8aPg9oDFIlu
da8952aba4b96c3d961836f4d202ff86d971954f: Bug 1413107 - Remove ending period in Custom Tabs Switch under Settings -> General r=nechen
Benjamin Cheng <chengwc@gmail.com> - Sun, 12 Nov 2017 02:38:18 +0800 - rev 393424
Push 97661 by rgurzau@mozilla.com at Thu, 23 Nov 2017 22:38:55 +0000
Bug 1413107 - Remove ending period in Custom Tabs Switch under Settings -> General r=nechen MozReview-Commit-ID: 9VmunM4BMox
255f29fb55cebf239ad14360b368b48b5cfc81c4: Bug 1413620 - Prefer Integer.valueOf over new Integer. r=nalexander,nechen
Andrew Gaul <andrew@gaul.org> - Wed, 01 Nov 2017 10:40:27 -0700 - rev 392070
Push 97391 by nbeleuzu@mozilla.com at Wed, 15 Nov 2017 23:49:34 +0000
Bug 1413620 - Prefer Integer.valueOf over new Integer. r=nalexander,nechen The former uses the Integer object cache to avoid allocations.
26428c0d82a295f14eccf3207cf0d91532da2898: Bug 1411968 - Only try launching BrowserApp when handling notifications; r=nechen
Jim Chen <nchen@mozilla.com> - Fri, 10 Nov 2017 18:26:18 -0500 - rev 391671
Push 97310 by ccoroiu@mozilla.com at Tue, 14 Nov 2017 10:32:21 +0000
Bug 1411968 - Only try launching BrowserApp when handling notifications; r=nechen Usually when we handle notification events, we try to launch whatever Activity showed the notification so that the user can see results. However, only BrowserApp supports being launched this way, so we should restrict launching Activites to BrowserApp. For others like CustomTabsActivity, we should just handle the notification event directly. Currently, only download notifications are supported for these other Activities, so it's okay if we don't display the Activity. MozReview-Commit-ID: CNVRSEWBOQ6
ca5529c5b2324352734feddb9c928192b8350a56: Bug 1411968 - Only try launching BrowserApp when handling notifications; r=nechen
Jim Chen <nchen@mozilla.com> - Fri, 10 Nov 2017 18:26:18 -0500 - rev 391580
Push 97297 by ncsoregi@mozilla.com at Mon, 13 Nov 2017 23:01:19 +0000
Bug 1411968 - Only try launching BrowserApp when handling notifications; r=nechen Usually when we handle notification events, we try to launch whatever Activity showed the notification so that the user can see results. However, only BrowserApp supports being launched this way, so we should restrict launching Activites to BrowserApp. For others like CustomTabsActivity, we should just handle the notification event directly. Currently, only download notifications are supported for these other Activities, so it's okay if we don't display the Activity. MozReview-Commit-ID: CNVRSEWBOQ6
7e505b1a27ad28dcba4b83f7db51b35406be17fc: Bug 1414995: Crash when publicsuffixlist could not be opened. r=nechen
Michael Comella <michael.l.comella@gmail.com> - Mon, 06 Nov 2017 16:12:15 -0800 - rev 391105
Push 97202 by nerli@mozilla.com at Fri, 10 Nov 2017 10:46:38 +0000
Bug 1414995: Crash when publicsuffixlist could not be opened. r=nechen MozReview-Commit-ID: 2agnVzKLkzd
e46ec8edd9bae2509c417040453dcb695efba328: Bug 1414838 - Show stop button again as soon as page loading starts. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 06 Nov 2017 20:20:57 +0100 - rev 390459
Push 97048 by archaeopteryx@coole-files.de at Tue, 07 Nov 2017 11:06:30 +0000
Bug 1414838 - Show stop button again as soon as page loading starts. r=nechen As of bug 1366672, case START no longer falls through in order to allow for a different behaviour of the progress indicator, however we still need to add UpdateFlags.PROGRESS, so that the stop button shows up as soon as a page starts loading. MozReview-Commit-ID: 3P33JEsS5ic
528162af9e015232a1240d2761e8028634852057: Bug 1412872 - 7. Move background events to GeckoApplication; r=nechen
Jim Chen <nchen@mozilla.com> - Wed, 01 Nov 2017 14:54:04 -0400 - rev 389601
Push 96894 by nchen@mozilla.com at Wed, 01 Nov 2017 18:55:40 +0000
Bug 1412872 - 7. Move background events to GeckoApplication; r=nechen Move the "Bookmark:Insert" and "Image:SetAs" events from GeckoApp to GeckoApplication. These events are global to the application, and they operate on the background thread, which will no longer be an option for the GeckoView event dispatcher. MozReview-Commit-ID: 8kesv8sJ8At
44455b744ee8b02c20d2c07d4b4ee4d50f3c0e77: Bug 1405215 - Part 2 - Make new Edit Bookmark dialogue scrollable. r=jwu,nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 19 Oct 2017 18:07:32 +0200 - rev 389406
Push 96855 by archaeopteryx@coole-files.de at Tue, 31 Oct 2017 23:40:37 +0000
Bug 1405215 - Part 2 - Make new Edit Bookmark dialogue scrollable. r=jwu,nechen Otherwise - the keyboard pushes the toolbar with the "Save" button out of view when entering text into the last input field - the last input field isn't even accessible in landscape orientation. MozReview-Commit-ID: 98Si6JfLt9m
41053a4acfa1b0abecbf32392259b1f32c843eac: Bug 1395370: BaseTest -> OldBaseTest. r=nechen
Michael Comella <michael.l.comella@gmail.com> - Mon, 23 Oct 2017 09:22:42 -0700 - rev 387998
Push 96545 by acraciun@mozilla.com at Wed, 25 Oct 2017 09:37:39 +0000
Bug 1395370: BaseTest -> OldBaseTest. r=nechen MozReview-Commit-ID: 5chsKoG2nxD
a684fee00172988f384f79f74814ff9fcbc8069e: Bug 1395370: Add deprecation to BaseTest. r=nechen
Michael Comella <michael.l.comella@gmail.com> - Mon, 23 Oct 2017 09:20:34 -0700 - rev 387997
Push 96545 by acraciun@mozilla.com at Wed, 25 Oct 2017 09:37:39 +0000
Bug 1395370: Add deprecation to BaseTest. r=nechen MozReview-Commit-ID: J6Kl14vkNdX
d5ba7b6469c7bcc3af9cd6ecef1587ae5a7d6b4b: Bug 1410975 - Support recording audio via supported app from the file picker. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 23 Oct 2017 21:10:50 +0200 - rev 387993
Push 96545 by acraciun@mozilla.com at Wed, 25 Oct 2017 09:37:39 +0000
Bug 1410975 - Support recording audio via supported app from the file picker. r=nechen Unlike capturing images/videos, the Android permission for recording audio is apparently only required if we want to record the audio ourselves, but not if we're merely calling out to some other app via MediaStore.Audio.Media.RECORD_SOUND_ACTION. Therefore we can drop that permission request for now. MozReview-Commit-ID: 35vtm8Y78hh
51484f33898df80318c982ccc5bf8218c81185b0: Bug 1362919 - Allow falling back to basic file picker if permissions are denied. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 23 Oct 2017 18:43:45 +0200 - rev 387982
Push 96545 by acraciun@mozilla.com at Wed, 25 Oct 2017 09:37:39 +0000
Bug 1362919 - Allow falling back to basic file picker if permissions are denied. r=nechen Theoretically this patch would also handle the case where the user has granted only some of the requested permissions, but at the moment our Permissions implementation doesn't make it easy to find out *which* permissions have been denied in the fallback case. So for the time being, we assume having no permissions at all in the fallback case. MozReview-Commit-ID: EtxFfiLQONF
5e992675a27da649fd41e9b7c26bd68155735436: Bug 1410338 - Incorrect color for History Panel message. r=nechen
Nevin Chen(:nechen) <cnevinchen@gmail.com> - Mon, 23 Oct 2017 12:06:21 +0800 - rev 387687
Push 96487 by archaeopteryx@coole-files.de at Mon, 23 Oct 2017 21:55:46 +0000
Bug 1410338 - Incorrect color for History Panel message. r=nechen MozReview-Commit-ID: A1QmvbFt7ok