searching for reviewer(sebastian)
04f47021f97c64a8584102d91be80ec57ca47843: Bug 1354973 - Remove view before add to new ViewGroup, r=sebastian. a=gchang
maliu <max@mxli.us> - Mon, 10 Apr 2017 11:48:59 +0800 - rev 375961
Push 11066 by ihsiao@mozilla.com at Tue, 18 Apr 2017 08:21:05 +0000
Bug 1354973 - Remove view before add to new ViewGroup, r=sebastian. a=gchang MozReview-Commit-ID: 1Xdlbss6SVO
ee6e9f3833ea3bd9a57488e9c0d9d4702dd4df35: Bug 1338867 - Strip username/password after strip reader mode url prefix. r=sebastian, a=lizzard
maliu <max@mxli.us> - Tue, 14 Mar 2017 14:07:57 +0800 - rev 375837
Push 11040 by ryanvm@gmail.com at Mon, 10 Apr 2017 16:04:28 +0000
Bug 1338867 - Strip username/password after strip reader mode url prefix. r=sebastian, a=lizzard MozReview-Commit-ID: KCr7cBdetq7
92ba21762445f89ae0691c4eab0746ca1cb819c2: Bug 1321418 - Update menu items using the correct ID. r=sebastian, a=lizzard
Jim Chen <nchen@mozilla.com> - Wed, 05 Apr 2017 14:23:44 -0400 - rev 375799
Push 11029 by ryanvm@gmail.com at Fri, 07 Apr 2017 02:58:00 +0000
Bug 1321418 - Update menu items using the correct ID. r=sebastian, a=lizzard Regression caused by an incorrect ID used to update menu items.
957849c3018f5e549f0acf9a2929f25ba4b63c41: Bug 1350661 - Extract layout attributes into styles in order to separate api 15 and 17 style tree. r=sebastian, a=gchang
maliu <max@mxli.us> - Mon, 16 Jan 2017 15:32:59 +0800 - rev 375790
Push 11028 by ryanvm@gmail.com at Thu, 06 Apr 2017 22:49:27 +0000
Bug 1350661 - Extract layout attributes into styles in order to separate api 15 and 17 style tree. r=sebastian, a=gchang __Device_Configuration__|__o_Applied_Style_______________ ldrtl-v17 v17 v15 | o o o | UrlBar.Entry \ | | | -----o | | UrlBar.V17.Entry(start/end) \ | | \ o | UrlBar.V15.Entry(left/right) \ | | --o | UrlBar.Base.Entry(original style) Though Android support RTL since API level 17(JB_MR1), it's really buggy at that moment. This patch fix a severe UI layout attribute bug, which only happen on android 4.2 in RTL language context: If view attributes "start/end" and "left/right" are both written in a view layout xml, they will both be applied and cause UI abnormal. In API 18 and above, "left" will be ignored if "start" also exist. For example, as below show, alignLeft and alignStart are both exist in ImageView. On android 4.2 with RTL context, it's width will both align Left and Start(Right), cause the symptom that ImageView have the same width and cover on the view "back." ``` <ImageView android:id="@+id/url_bar_entry" android:layout_alignLeft="@+id/back" android:layout_alignStart="@+id/back" ``` MozReview-Commit-ID: JptLuWX2w15
9d164f1dc3c2eac75e31c57aa294b5a4d1b0030a: Bug 1351964 - Use UI thread for "Tabs:TabsOpened" event. r=sebastian, a=lizzard
Jim Chen <nchen@mozilla.com> - Wed, 05 Apr 2017 14:23:44 -0400 - rev 375763
Push 11023 by ryanvm@gmail.com at Thu, 06 Apr 2017 11:09:41 +0000
Bug 1351964 - Use UI thread for "Tabs:TabsOpened" event. r=sebastian, a=lizzard Use the UI thread for handling "Tabs:TabsOpened", so we don't race with other tab events that are already handled on the UI thread.
578e94e40a70a5ba175857ada48c7a15cbd00473: Bug 1325955 - Prevent providing wrong baseDomain if scheme is not recognized r=sebastian a=gchang
Julian_Chu <walkingice0204@gmail.com> - Thu, 16 Mar 2017 18:12:04 +0800 - rev 375463
Push 10957 by cbook@mozilla.com at Mon, 27 Mar 2017 10:46:38 +0000
Bug 1325955 - Prevent providing wrong baseDomain if scheme is not recognized r=sebastian a=gchang If location change to some special scheme, we might misuse the location to parse domain. Now only get base domain from host if the scheme is recognized.(http/https/ftp) MozReview-Commit-ID: 4MkrNfsUJqQ --- mobile/android/chrome/content/browser.js | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-)
b364c6b8169d20e86287510bc6d3fbdb6dded75e: Bug 1346171 - Part 2 - Test synchronous session file deletion on clearing history. r=sebastian a=lizzard
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 12 Mar 2017 11:13:33 +0100 - rev 375186
Push 10892 by kwierso@gmail.com at Mon, 13 Mar 2017 19:01:11 +0000
Bug 1346171 - Part 2 - Test synchronous session file deletion on clearing history. r=sebastian a=lizzard MozReview-Commit-ID: JUrbSD2t41t
2cf57400546eda653c5857b69b1b7f2aa1ff3174: Bug 1346171 - Part 1 - Check correct file before attempting do delete it. r=sebastian a=lizzard
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 12 Mar 2017 11:13:22 +0100 - rev 375185
Push 10892 by kwierso@gmail.com at Mon, 13 Mar 2017 19:01:11 +0000
Bug 1346171 - Part 1 - Check correct file before attempting do delete it. r=sebastian a=lizzard MozReview-Commit-ID: 29UT51xRoVN
df546ad502ce5b4dcbef7af3994be15cca97462f: Bug 1216489 - 3. Remove unnecessary touch intercept code for TabsPanel. r=sebastian
Tom Klein <twointofive@gmail.com> - Wed, 30 Nov 2016 18:30:57 -0600 - rev 374476
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1216489 - 3. Remove unnecessary touch intercept code for TabsPanel. r=sebastian MozReview-Commit-ID: 7pf9GRLgHXg
baa3bfef08bd89510532275fb2fa91616a34c1da: Bug 1216489 - 2. Cleanup width and height calculations in TabsPanel. r=sebastian
Tom Klein <twointofive@gmail.com> - Wed, 30 Nov 2016 17:31:37 -0600 - rev 374475
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1216489 - 2. Cleanup width and height calculations in TabsPanel. r=sebastian MozReview-Commit-ID: I1chEZDnOyR
b96ede86735972a43f0ee84954887763b4d6ab37: Bug 1216489 - 1. Cleanup TabsPanel includes and remove member variable. r=sebastian
Tom Klein <twointofive@gmail.com> - Wed, 30 Nov 2016 17:02:53 -0600 - rev 374474
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1216489 - 1. Cleanup TabsPanel includes and remove member variable. r=sebastian MozReview-Commit-ID: 9eTBEf8xj1l
8a62afb4f1790a2d78d0a9f8cdfa5d20fba9f71b: Bug 1340929 - Don't scroll to a new tab opened from a link. r=sebastian
Tom Klein <twointofive@gmail.com> - Wed, 22 Feb 2017 21:54:11 -0600 - rev 374473
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1340929 - Don't scroll to a new tab opened from a link. r=sebastian We used to scroll in addTab to make sure a new tab created by a close-tab-undo at the start or the end of the list was made visible instead of staying where it was created off the edge. We're now taking care of that in selectTab (where it should have stayed in the first place), where the select in that case occurs between the time when the new tab is added to the adapter and when the layout gets updated. In the case where the new tab is at the start, that means the check 'position < layoutManager.findFirstCompletelyVisibleItemPosition()' in selectTab reads '0 < 0', which fails (which is why we need the new check for 'position == 0'), but the check 'position > layoutManager.findLastCompletelyVisibleItemPosition()' for a tab added at the end reads 'new_lengh -1 > old_length - 1' which already passes, so we don't need a special case for undo-tab-close adds at the end in selectTab. Tabs added at the end by a normal "create new tab" still scroll for the same reason. Robotium was confused by the duplicate 'add_tab' ids from the tab strip and the tabs panel, so I renamed one of them. Also note that the 'getTabId' added to TabStripItemView for testing already exists on TabLayoutItemView, but the two classes don't share a common base. MozReview-Commit-ID: BzG2r8BSs90
b25d9cfea3f9b5b822109af7ea4d90ae04463a7e: Bug 1337115 - Part 2 - Send telemetry if session restore completely fails and we're not on the first run. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 17 Feb 2017 20:02:33 +0100 - rev 374470
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337115 - Part 2 - Send telemetry if session restore completely fails and we're not on the first run. r=sebastian For a fresh profile it is expected that there are no session files to restore from, however afterwards we should normally always have a valid - if possibly empty - session file available. We try excluding the first run case by checking the first run pref used by Telemetry so far and see whether we get any reasonable results out of this... MozReview-Commit-ID: 2ZxmLqwhk32
1f45e38b27af6a061a9b71dcdff3cf9074d4b629: Bug 1337115 - Part 1 - Make "Is first run" pref generally useable. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 23 Feb 2017 22:16:26 +0100 - rev 374469
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337115 - Part 1 - Make "Is first run" pref generally useable. r=sebastian This pref could be useful for things outside of the TelemetryCorePingDelegate as well, so we have it live in GeckoApp now. MozReview-Commit-ID: 2JZ3vNqSzcl
32524eee28c5d59138e42526255d77ee884ffb38: Bug 1331995 - Reset text direction to locale in order to reveal text hint, checkstyle, r=sebastian
maliu <max@mxli.us> - Wed, 01 Mar 2017 18:34:59 +0100 - rev 374460
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1331995 - Reset text direction to locale in order to reveal text hint, checkstyle, r=sebastian
a0d02ea2773152926486f5b39f6fe83954e5c400: Bug 1341527 - Add restrictions mocking to SuggestedSitePreparer test r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Thu, 23 Feb 2017 14:09:04 -0800 - rev 374436
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1341527 - Add restrictions mocking to SuggestedSitePreparer test r=sebastian MozReview-Commit-ID: 6Eii88A5IHN
9f67d8a507479b15022bce420752b6d7c456a01e: Bug 1341527 - Move UserManager mocking into helper class r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Thu, 23 Feb 2017 14:08:51 -0800 - rev 374435
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1341527 - Move UserManager mocking into helper class r=sebastian We need this for more than one test, let's have one copy we can call from wherever it's needed. MozReview-Commit-ID: Bd0o38KcqQc
093c7e787c9b1523b3364fdaac7a4481106002ca: Bug 1342105 - actually return if suggested site data is missing r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Thu, 23 Feb 2017 09:17:05 -0800 - rev 374434
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1342105 - actually return if suggested site data is missing r=sebastian MozReview-Commit-ID: GdshIa0e5Cj
9c6a7e1b3f61b0e6c88f641d91cabb3ed6240c2b: Bug 1342968 - Remove unused TabsLayout xml style attributes. r=sebastian
Tom Klein <twointofive@gmail.com> - Mon, 27 Feb 2017 10:20:36 -0600 - rev 374431
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1342968 - Remove unused TabsLayout xml style attributes. r=sebastian All TabsLayouts are RecyclerViews now. * Orientation on a RecyclerView is set on the LayoutManager, not the RecyclerView; * android:listSelector doesn't apply to RecyclerView; * android:choiceMode doesn't apply to RecyclerView. This patch also fixes bug 1337699 when it removes the old android:scrollbars="horizontal" in values-land/styles.xml from back when the tabs tray scrolled horizontally in landscape mode. MozReview-Commit-ID: 97el99fSi5o
c6a264b47ece8d056a3c709dcf9978059557ba2b: Bug 1331995 - Reset text direction to locale in order to reveal text hint, r=sebastian
maliu <max@mxli.us> - Wed, 01 Mar 2017 14:04:52 +0800 - rev 374407
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1331995 - Reset text direction to locale in order to reveal text hint, r=sebastian MozReview-Commit-ID: I1FIL7QDRSu
f1b38b06e80c2bcadf738cfe58c0f9162dc0d971: Bug 1342718 - Don't query for search engine suggestions if we're not displaying them. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 26 Feb 2017 13:39:49 +0100 - rev 374401
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1342718 - Don't query for search engine suggestions if we're not displaying them. r=sebastian If the user has deactivated search suggestions (either live suggestions from the search engine or those coming from our history), we shouldn't even bother to restart the corresponding loader in that case, so as to avoid - wasting processing and network resources - and perhaps more importantly, not leaking the user's search terms to the default search engine if the user doesn't want that kind of suggestions. At the moment we only exit early from filterSuggestions() when in private mode or if both kinds of search suggestions have been deactivated, but we don't properly handle the case where only one kind of search suggestions has been deactivated. This should also improve the display of search history results if the user has deactivated the display of live search suggestions, since currently duplicates between the fresh suggestions and the search history are always removed from the latter even when we're not displaying the former. MozReview-Commit-ID: IOTMLRaZeyP
da494e30eb87f4ff827cbb3ffe7923694bc49c8c: Bug 1337692 - Ask for permission on input=file/accept. r=sebastian,grisha
cnevinchen@gmail.com - Mon, 27 Feb 2017 21:02:00 -0600 - rev 374170
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337692 - Ask for permission on input=file/accept. r=sebastian,grisha
750d9da36fc7469985e2921c182e843cb567de27: Bug 1323366 - Create new IconRequest to prevent ConcurrentModificationException, r=sebastian
Jing-wei Wu <topwu.tw@gmail.com> - Mon, 20 Feb 2017 09:45:16 +0800 - rev 374012
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1323366 - Create new IconRequest to prevent ConcurrentModificationException, r=sebastian
ea22d7caa61894c693987966aa2c2a5c984f3ed9: Bug 1340957 - Don't rely on SuggestedSites being loaded r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Tue, 21 Feb 2017 08:21:56 -0800 - rev 373763
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1340957 - Don't rely on SuggestedSites being loaded r=sebastian MozReview-Commit-ID: JjWurcyDoWQ
4e3d73a1b3b4cf6c671602b70162ff32007b559a: Bug 1340960 - Correctly invoke print callbacks; r=sebastian
Jim Chen <nchen@mozilla.com> - Wed, 22 Feb 2017 23:10:17 -0500 - rev 373489
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1340960 - Correctly invoke print callbacks; r=sebastian generatePDF returns a Promise. We shouldn't feed the Promise to the callback, but rather invoke the callbacks when the Promise is resolved/rejected.
c94cfb6232488d62ff84ed32c021afb5925040d0: Bug 1337459 - Update to selected tab when ToolbarDisplayLayout is ready; r=sebastian
Jim Chen <nchen@mozilla.com> - Wed, 22 Feb 2017 23:10:16 -0500 - rev 373488
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337459 - Update to selected tab when ToolbarDisplayLayout is ready; r=sebastian We don't update ToolbarDisplayLayout when it's not ready (i.e. when it's not attached to a window yet), but when it does become ready, we should update it to the selected tab, if any.
925704aab093cb0704b88a6a208ad6a11c4a90f1: Bug 1326114 - only do duration checking for active-media. r=sebastian
Alastor Wu <alwu@mozilla.com> - Thu, 23 Feb 2017 12:13:49 +0800 - rev 373386
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1326114 - only do duration checking for active-media. r=sebastian Since we don't want to show the media control for the short sound, so we added the duration checking. And this checking only needs to be run when the media is active, we don't need to check the inactive media. MozReview-Commit-ID: AaVGi77nXJ1
212bad17569eb87422dbbde1c8290650c7f64bbe: Bug 1339066 - Don't add a private tab opened while viewing the normal-mode tab strip. r=sebastian
Tom Klein <twointofive@gmail.com> - Thu, 16 Feb 2017 07:25:54 -0600 - rev 373382
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1339066 - Don't add a private tab opened while viewing the normal-mode tab strip. r=sebastian MozReview-Commit-ID: AZEZq4boaJW
9294b1e9b7e2c0b0b6a74e4d22634874433f11e4: Bug 1340191 - reverse the checking condition. r=sebastian
Alastor Wu <alwu@mozilla.com> - Wed, 22 Feb 2017 15:51:08 +0800 - rev 373380
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1340191 - reverse the checking condition. r=sebastian Since BBC website puts their audio in another iframe, we can't get the media element to check its duration, so we always return false. The ideal way to fix it is to get every iframe and check its element, but I think it's not very easy to do considering the flexibility of using iframe and the cost time. First, if we want to get the information inside iframe, we need to listen the onload event, but it's async operation. If there are lots iframe, we need to spend lots time to wait every iframe. The worst situation is we got the nested iframe, it would need lots time and effect to wait every iframe loaded and get the element we want. Therefore, I would prefer the workaround which is to reverse the checking condition, that is we only check duration for the main window. MozReview-Commit-ID: F93BjbzRMXO
289af83c670221c520b9c4834219e967be826982: Bug 1340875 - Send the URL and title of the history entry that was actually open when the tab was closed. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 19 Feb 2017 15:05:39 +0100 - rev 373352
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1340875 - Send the URL and title of the history entry that was actually open when the tab was closed. r=sebastian Currently, Recently Closed is displaying the last available history entry for each closed tab instead of the history entry that was actually being shown at the time the tab was closed. The Java session parser that is responsible for displaying the last session's tabs when not automatically restoring is already doing the correct thing and therefore doesn't need changing. MozReview-Commit-ID: DGaD52SzdpP
29415857b3cc9219bec0e99a30d774bbbd657774: Bug 1339519 - Set "pending" attribute on browser when creating a new delay-loaded tab. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 17 Feb 2017 18:43:52 +0100 - rev 372665
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1339519 - Set "pending" attribute on browser when creating a new delay-loaded tab. r=sebastian I don't think we ever check this attribute in our code and rely on the presence of "__SS_restore" instead, but we should fix this for consistency and any add-ons or future code that might depend on this. MozReview-Commit-ID: JwB6kpiKsaR
84757ceb6decdb0332f1ef73ac6af828b839ace4: Bug 1340175 - Remove WRITE_CONTACTS permission from Android mozrunner; r=sebastian
Geoff Brown <gbrown@mozilla.com> - Thu, 16 Feb 2017 15:31:22 -0700 - rev 372458
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1340175 - Remove WRITE_CONTACTS permission from Android mozrunner; r=sebastian
c200a723f3586b5797621524fdbc20e97df0ffba: Bug 1339520 - Keep existing TopPanel when cursor is swapped r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Thu, 16 Feb 2017 18:42:46 -0800 - rev 372409
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1339520 - Keep existing TopPanel when cursor is swapped r=sebastian By default RecyclerView assumes any item change *might* need animation. It then creates a new copy of the item that has changed, and interpolates between the two to "animate" the change. We don't need that for topsites (the RecyclerView's we use inside each TopSitePanel already animate changes, the overall size doesn't change - moreover ViewPager state gets lost if you create a new panel), so we override this behaviour to retain the existing panel. This stops the previously visible horrible flickering. (Every time history changes, which can happen if sync is working, or even if a page finishes loading in the background, the DB is changed, and a reload is triggered. Prior to this commit, topsites would flicker horribly, and would reset back to the first topsites page. After this commit the page is retained, and the visible topsites are rearranged by the inner RecyclerView's animations. You can test this by pinning a site on the first page, the pinned site will shift to the front, the other sites smoothly move to the right.) MozReview-Commit-ID: CnocNfdQ2FS
48f725d09c7a298b3a7f34f5a552749f930b2ac7: Bug 1339520 - Don't refresh topsites pages, only modify if needed r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Thu, 16 Feb 2017 18:39:08 -0800 - rev 372408
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1339520 - Don't refresh topsites pages, only modify if needed r=sebastian If we clear and recreate pages every time the cursor changes, we'll (A) lose the current page position and (B) create a new RecyclerView per page, resulting in flickering. We also need to make sure positioning is correctly handled (i.e. pages never move, they only get added or removed). We also switch to an ArrayList: the number of pages will be fixed for most users, and searching an ArrayList could potentially be slightly faster than with the LinkedList. There's little advantage to a LinkedList here. MozReview-Commit-ID: 6NIfc2otQMV
0cfcc10ad05c6bb6d8b6494b5648950169d588ff: Bug 1320775 - Add tests for SuggestedSiteLoader/Preparer r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Wed, 08 Feb 2017 16:37:30 -0800 - rev 372159
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1320775 - Add tests for SuggestedSiteLoader/Preparer r=sebastian MozReview-Commit-ID: GXB4Ott4MAi
aeab7252c1165587c58d42e5cb835650129a1df7: Bug 1320775 - Use bundled touch-tiles as favicons for suggested sites r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Wed, 08 Feb 2017 15:15:12 -0800 - rev 372158
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1320775 - Use bundled touch-tiles as favicons for suggested sites r=sebastian There are a number of ways in which we could supply favicons for the default suggested sites. Reusing the touch tiles has the advantage that it works for both our own suggested sites, and also distribution-supplied suggested sites. If we were to add yet another icon source, distribution supplied sites would end up having no nice icon in AS topsites. The priority ordering of the SuggestedSitePreparer means icons will be overriden as soon as a site-supplied favicon is available - these icons will only be used up until the point where a site has been visited. MozReview-Commit-ID: CHsinHHpfnw
04d7cacd46f957f7185ca27edb142a8b989fdeec: Bug 1320775 - Pre: move favicon colour fading to color generator r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Wed, 08 Feb 2017 10:12:24 -0800 - rev 372157
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1320775 - Pre: move favicon colour fading to color generator r=sebastian In order to allow for a background which merges into a favicon, we need to allow for solid (non faded) colours. It is simplest to do this by letting the colour generator (i.e. either the colour extractor, or the favicon generator) fade the dominant colour as it wishes. That also means the colour generator can in future choose to not fade the colour if appropriate. MozReview-Commit-ID: LsI8PlZsaGn
742e4f33e3d63874bea1105c5993b2dca7933952: Bug 1312686 - Link "default browser" setting to app info screen on Android 7+; r=sebastian
brainbreaker <gautamprajapati06@gmail.com> - Wed, 15 Feb 2017 02:27:26 +0530 - rev 372070
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1312686 - Link "default browser" setting to app info screen on Android 7+; r=sebastian Added support for changing default browser by opening settings screen in API Levels >=24. MozReview-Commit-ID: 5rxJm6hQQ4A
7697b05969f820be687ae70332f8dcf6956fa2fa: Bug 1325931 - Use compound drawable text centering hack for AS Topsites r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Thu, 09 Feb 2017 13:27:20 -0800 - rev 371869
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1325931 - Use compound drawable text centering hack for AS Topsites r=sebastian MozReview-Commit-ID: 4reNZTHHZNw
596c114a25248f923e98a8a2b1995b7c249ce23c: Bug 1325931 - Implement ViewUtil.setCenteredText() for TextViews with compound drawables r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Thu, 09 Feb 2017 13:26:43 -0800 - rev 371868
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1325931 - Implement ViewUtil.setCenteredText() for TextViews with compound drawables r=sebastian Compound drawables shift the point where text is "centered". This hack dynamically adds equivalent padding on the opposite side from a compound drawable, to force the text to be centered again. (We can't set this padding under all circumstances, it's unneeded when the text is longer than the available space, i.e. when we wrap text we might as well use the full width without fake padding.) MozReview-Commit-ID: 8WDXCNOs2DX
d5d12ac7e213e654ad01364aca38ec00f6bf4c0a: Bug 1325931 - Pre: add drawable padding to pin r=sebastian
Andrzej Hunt <ahunt@mozilla.com> - Thu, 09 Feb 2017 13:24:24 -0800 - rev 371867
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1325931 - Pre: add drawable padding to pin r=sebastian Text is currently pushed directly against the pin in those cases where the entire width is filled with text - this spacing is needed to separate the pin, and text. MozReview-Commit-ID: HOVH1SgcrLY
6b89d6cdb5f680bcc7c5a6482766fdac6f8af576: Bug 1338899 - Part 1 - Use getter/setter for accessing/modifying a tab's parent ID in Gecko. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 12 Feb 2017 15:34:00 +0100 - rev 371572
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1338899 - Part 1 - Use getter/setter for accessing/modifying a tab's parent ID in Gecko. r=sebastian This should be more foolproof than having to remember to use the dedicated setParentId() function when writing to that variable from outside of the tab constructor. MozReview-Commit-ID: 1KlXf60VsoF
e8b1868152413169b2179054851a2bfde9f51f24: Bug 1338899 - Part 0 - Fix test title. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 12 Feb 2017 15:25:42 +0100 - rev 371571
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1338899 - Part 0 - Fix test title. r=sebastian Fix copy & paste error made when creating the new test file. MozReview-Commit-ID: F0NbwipkX9P
3bfcb88ae88d2372fc8dd14203194cc965652512: Bug 1338893 - Don't use the window on application-foreground if it doesn't yet exist. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 12 Feb 2017 15:09:32 +0100 - rev 371570
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1338893 - Don't use the window on application-foreground if it doesn't yet exist. r=sebastian During a cold startup, depending how this exactly plays out we might receive an application-foreground notification before the browser window is ready. Since the code to restore the selected tab if it has been left zombified while in background is only relevant if Gecko was already running and backgrounded, we can simply add a null check for the window before accessing it. MozReview-Commit-ID: Ahp5NAODKRF
94a2ac4a5806ed8549885866537f813d8af9cb96: Bug 1337264 - Don't depend on page title changes for updating the displayed URL. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 11 Feb 2017 17:12:48 +0100 - rev 371568
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1337264 - Don't depend on page title changes for updating the displayed URL. r=sebastian We've been displaying the URL in place of the page title in the toolbar for quite some time now, but still had the old logic in place whereby only title changes would trigger an update of the displayed text. Most of the time this works fine, because - page navigation usually goes hand in hand with a DOMTitleChanged event, and - when our loading progress bar stops, we update the displayed text anyway however a page doing its navigation in-place using some fancy JS logic and the corresponding history APIs etc. can bypass both of these provisions, since it might trigger neither a title change nor a full browser-side page load. MozReview-Commit-ID: KRrTSmz1xxi
be42accd3a48b430e663bc4d22cece2ff2585b21: Bug 1336734 - Part 2 - Don't stop the GeckoNetworkManager unless we're really backgrounded. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 05 Feb 2017 15:47:51 +0100 - rev 371360
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336734 - Part 2 - Don't stop the GeckoNetworkManager unless we're really backgrounded. r=sebastian Launching a new activity within our app triggers both onActivityPause() (the current activity) and onActivityResume() (the new activity) in GeckoApplication. The most prominent example at the moment are probably our preferences - entering/exiting/navigating within them always triggers a pause/resume combo. This means that currently each time this happens, the network manager is stopped only to be immediately restarted. To prevent this, we now stop the network manager only when Gecko is actually being paused. In order to avoid unmatched start/stop calls, we need to treat the calls to start() similarly and provide an additional code path for the initial call to start() immediately after startup. Since the BatteryManager is only started and currently never stopped, we can use this for its startup, too, so as to avoid duplicated calls to its start() method. MozReview-Commit-ID: 6NdScT5cLYL
b5d12d30e6cfa3d6e9291c2b9a0e0a6299b422e1: Bug 1336734 - Part 1 - Have GeckoPreferences properly support GeckoActivityStatus. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 05 Feb 2017 15:35:00 +0100 - rev 371359
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336734 - Part 1 - Have GeckoPreferences properly support GeckoActivityStatus. r=sebastian Currently, GeckoPreferences always returns "false" for isGeckoActivityOpened(), which means that when we're e.g. opening a new settings screen, GeckoApplication's onActivityPause() code assumes that Firefox is being backgrounded for real, calling GeckoThread.onPause(). This is then immediately followed by a call to onActivityResume() which unpauses Gecko again. To avoid this, GeckoPreferences needs to properly implement support for GeckoActivityStatus and check the target of outgoing intents along the lines of the implementation in GeckoActivity. Since checkIfGeckoActivity() is now used outside GeckoActivity as well, we refactor it into our IntentUtils. MozReview-Commit-ID: UfPNAic5os
a7f9815aeec179cc07610cf9e914739ca85268ac: Bug 1336734 - Part 3 - Don't stop the GeckoNetworkManager unless we're really backgrounded. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 05 Feb 2017 15:47:51 +0100 - rev 371348
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336734 - Part 3 - Don't stop the GeckoNetworkManager unless we're really backgrounded. r=sebastian Launching a new activity within our app triggers both onActivityPause() (the current activity) and onActivityResume() (the new activity) in GeckoApplication. The most prominent example at the moment are probably our preferences - entering/exiting/navigating within them always triggers a pause/resume combo. This means that currently each time this happens, the network manager is stopped only to be immediately restarted. To prevent this, we now stop the network manager only when Gecko is actually being paused. In order to avoid unmatched start/stop calls, we need to treat the calls to start() similarly and provide an additional code path for the initial call to start() immediately after startup. Since the BatteryManager is only started and currently never stopped, we can use this for its startup, too, so as to avoid duplicated calls to its start() method. MozReview-Commit-ID: 6NdScT5cLYL
fa9cca3e321cdfbae259d4d204b8c393a2d1774e: Bug 1336734 - Part 2 - Implement GeckoActivityStatus for the FxAccountStatusActivity. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 06 Feb 2017 20:30:20 +0100 - rev 371347
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336734 - Part 2 - Implement GeckoActivityStatus for the FxAccountStatusActivity. r=sebastian Since we're no longer pausing Gecko when entering this activity, it must implement this interface so we can still properly pause Gecko if we get backgrounded while on the Sync preferences screen. Most actions here are actually done via the application context (i.e. GeckoApplication), so overriding startActivity et al. and using mGeckoActivityOpened doesn't achieve all that much for most cases, but since we currently at most exit the screen (activity is finishing, so won't trigger a GeckoThread.onPause() call) and stay within our application (open a new tab in Firefox), we're still fine for now. MozReview-Commit-ID: 3760hXMjckX
a2b69382c9adc18d2eec5e63088303832cacddf8: Bug 1336734 - Part 1 - Have GeckoPreferences properly support GeckoActivityStatus. r=sebastian
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 05 Feb 2017 15:35:00 +0100 - rev 371346
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336734 - Part 1 - Have GeckoPreferences properly support GeckoActivityStatus. r=sebastian Currently, GeckoPreferences always returns "false" for isGeckoActivityOpened(), which means that when we're e.g. opening a new settings screen, GeckoApplication's onActivityPause() code assumes that Firefox is being backgrounded for real, calling GeckoThread.onPause(). This is then immediately followed by a call to onActivityResume() which unpauses Gecko again. To avoid this, GeckoPreferences needs to properly implement support for GeckoActivityStatus and check the target of outgoing intents along the lines of the implementation in GeckoActivity. Since checkIfGeckoActivity() is now used outside GeckoActivity as well, we refactor it into our IntentUtils. MozReview-Commit-ID: UfPNAic5os