e991f8efe6bf460b6dbdb42aeb9fdbfbe07b84b9: Bug 1351739 - Part 0 - Use INVALID_TAB_ID more. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 06 Apr 2017 21:30:55 +0200 - rev 568076
Push 55751 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:50:13 +0000
Bug 1351739 - Part 0 - Use INVALID_TAB_ID more. r?sebastian,walkingice -1 is probably not all that mysterious as far as magic numbers go, but still... MozReview-Commit-ID: zK3P6HeWzK
1427af92ea71fa10a3c32b1b079d659a205ad39c: Bug 1351739 - Part -1 - Housekeeping. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 07 Apr 2017 20:51:41 +0200 - rev 568075
Push 55751 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:50:13 +0000
Bug 1351739 - Part -1 - Housekeeping. r?sebastian,walkingice MozReview-Commit-ID: Ev6jl4N3K0g
b15218d9cd97d3371e89365fc472d0bcd2672861: Bug 1357117 part 3: Serialize -webkit-linear-gradient() expressions using the (less-expressive) -webkit-linear-gradient syntax, instead of -moz-linear-gradient. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 11:48:41 -0700 - rev 568074
Push 55750 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:48:48 +0000
Bug 1357117 part 3: Serialize -webkit-linear-gradient() expressions using the (less-expressive) -webkit-linear-gradient syntax, instead of -moz-linear-gradient. r=heycam Specifically: * This patch uses a flag added in a prior patch to let us use the author's chosen prefix (-webkit or -moz) when serializing. (We treat the -moz version as a special case, because that makes it more straightforward to unsupport -moz if/when we can.) * This patch makes us share the linear-gradient() side-or-corner serialization codepath when serializing points for -webkit-linear-gradient. (The alternative is the -moz-linear-gradient codepath, which defaults to serializing with percent values 0%/100% for sides & corners -- and raw percentages are invalid in -webkit-linear-gradient(), so we can't share that codepath.) Notably, we have to skip the "to " token that the linear-gradient() codepath would normally print out -- that was a late addition to the spec and so it only exists in the unprefixed modern syntax. (Instead, -webkit-linear-gradient syntax is implicitly "from" the given point). MozReview-Commit-ID: 9Oqo8nG1XDU
cabd4a140d575794a8a656c47692bb9d3a02de88: Bug 1357117 part 2: Add flag to distinguish between -moz & -webkit prefixed gradient expressions. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 11:48:39 -0700 - rev 568073
Push 55750 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:48:48 +0000
Bug 1357117 part 2: Add flag to distinguish between -moz & -webkit prefixed gradient expressions. r=heycam This patch doesn't change our behavior -- we won't actually act on the new flag until the next patch in this series. MozReview-Commit-ID: EONsLM54eG1
9f8b5c801b2f4352dd2ace3b79c40edb1795b361: Bug 1357117 part 1: Change linear-gradient serialization code to group space separator with the "to" token. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 11:48:37 -0700 - rev 568072
Push 55750 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:48:48 +0000
Bug 1357117 part 1: Change linear-gradient serialization code to group space separator with the "to" token. r=heycam This patch doesn't change our behavior -- we'll still produce the same serialization that we would've before. MOTIVATION: A later patch will make us share this codepath to serialize into -webkit-linear-gradient() syntax. That syntax uses the same representation for points as unprefixed modern linear-gradient() (with box-side-or-corner keywords "top", "right", etc.), but it does *not* use the word "to". So we'd like to allow "to"-and-its-subsequent-space-character to be optional. Hence, this patch groups the space together with "to", rather than as a prefix on the next token, so that we can skip right to printing the point (without a leading space) when we add support for -webkit-linear-gradient() serialization. MozReview-Commit-ID: 5fCzx4NmpcC
93b8b15845c8698effe12b1fbe2a2d28fc6e456c: Bug 1359501 - Accept artifact builds from beta. r=chmanchester draft
J. Ryan Stinnett <jryans@gmail.com> - Tue, 25 Apr 2017 12:12:16 -0500 - rev 568071
Push 55749 by bmo:jryans@gmail.com at Tue, 25 Apr 2017 18:47:43 +0000
Bug 1359501 - Accept artifact builds from beta. r=chmanchester MozReview-Commit-ID: 5a2NIi6U7n7
23da2ae1d6fdc051e0da82f673a8cec553563278: Bug 1357117 part 3: Serialize -webkit-linear-gradient() expressions using the (less-expressive) -webkit-linear-gradient syntax, instead of -moz-linear-gradient. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 11:46:47 -0700 - rev 568070
Push 55748 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:46:56 +0000
Bug 1357117 part 3: Serialize -webkit-linear-gradient() expressions using the (less-expressive) -webkit-linear-gradient syntax, instead of -moz-linear-gradient. r=heycam Specifically: * This patch uses a flag added in a prior patch to let us use the author's chosen prefix (-webkit or -moz) when serializing. (We treat the -moz version as a special case, because that makes it more straightforward to unsupport -moz if/when we can.) * This patch makes us share the linear-gradient() side-or-corner serialization codepath when serializing points for -webkit-linear-gradient. (The alternative is the -moz-linear-gradient codepath, which defaults to serializing with percent values 0%/100% for sides & corners -- and raw percentages are invalid in -webkit-linear-gradient(), so we can't share that codepath.) Notably, we have to skip the "to " token that the linear-gradient() codepath would normally print out -- that was a late addition to the spec and so it only exists in the unprefixed modern syntax. (Instead, -webkit-linear-gradient syntax is implicitly "from" the given point). MozReview-Commit-ID: 9Oqo8nG1XDU
2e1ca6d3b71b4193c3eb7aa8071c120e6f2a2edf: Bug 1357117 part 2: Add flag to distinguish between -moz & -webkit prefixed gradient expressions. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 11:46:45 -0700 - rev 568069
Push 55748 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:46:56 +0000
Bug 1357117 part 2: Add flag to distinguish between -moz & -webkit prefixed gradient expressions. r=heycam This patch doesn't change our behavior -- we won't actually act on the new flag until the next patch in this series. MozReview-Commit-ID: EONsLM54eG1
695294d8f9ee21f8f27ad3e5083d6be7e7363b3e: Bug 1357117 part 1: Change linear-gradient serialization code to group space separator with the "to" token. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 11:46:43 -0700 - rev 568068
Push 55748 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:46:56 +0000
Bug 1357117 part 1: Change linear-gradient serialization code to group space separator with the "to" token. r=heycam This patch doesn't change our behavior -- we'll still produce the same serialization that we would've before. MOTIVATION: A later patch will make us share this codepath to serialize into -webkit-linear-gradient() syntax. That syntax uses the same representation for points as unprefixed modern linear-gradient() (with box-side-or-corner keywords "top", "right", etc.), but it does *not* use the word "to". So we'd like to allow "to"-and-its-subsequent-space-character to be optional. Hence, this patch groups the space together with "to", rather than as a prefix on the next token, so that we can skip right to printing the point (without a leading space) when we add support for -webkit-linear-gradient() serialization. MozReview-Commit-ID: 5fCzx4NmpcC
23e8f4cf7d8adda0a81d66395d91709eee22856c: Bug 1357117 part 3: Serialize -webkit-linear-gradient() expressions using the (less-expressive) -webkit-linear-gradient syntax, instead of -moz-linear-gradient. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 11:44:43 -0700 - rev 568067
Push 55747 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:44:52 +0000
Bug 1357117 part 3: Serialize -webkit-linear-gradient() expressions using the (less-expressive) -webkit-linear-gradient syntax, instead of -moz-linear-gradient. r=heycam Specifically: * This patch uses a flag added in a prior patch to let us use the author's chosen prefix (-webkit or -moz) when serializing. (We treat the -moz version as a special case, because that makes it more straightforward to unsupport -moz if/when we can.) * This patch makes us share the linear-gradient() side-or-corner serialization codepath when serializing points for -webkit-linear-gradient. (The alternative is the -moz-linear-gradient codepath, which defaults to serializing with percent values 0%/100% for sides & corners -- and raw percentages are invalid in -webkit-linear-gradient(), so we can't share that codepath.) Notably, we have to skip the "to " token that the linear-gradient() codepath would normally print out -- that was a late addition to the spec and so it only exists in the unprefixed modern syntax. (Instead, -webkit-linear-gradient syntax is implicitly "from" the given point). MozReview-Commit-ID: 9Oqo8nG1XDU
cf56f0271e9c3c987866e97b5259e1e414d738d1: Bug 1357117 part 2: Add flag to distinguish between -moz & -webkit prefixed gradient expressions. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 09:55:25 -0700 - rev 568066
Push 55747 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:44:52 +0000
Bug 1357117 part 2: Add flag to distinguish between -moz & -webkit prefixed gradient expressions. r=heycam This patch doesn't change our behavior -- we won't actually act on the new flag until the next patch in this series. MozReview-Commit-ID: EONsLM54eG1
32b27bd6c2be65a68f88e920c93ea143485e9651: Bug 1357117 part 1: Change linear-gradient serialization code to group space separator with the "to" token. r=heycam draft
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 25 Apr 2017 09:55:23 -0700 - rev 568065
Push 55747 by dholbert@mozilla.com at Tue, 25 Apr 2017 18:44:52 +0000
Bug 1357117 part 1: Change linear-gradient serialization code to group space separator with the "to" token. r=heycam This patch doesn't change our behavior -- we'll still produce the same serialization that we would've before. MOTIVATION: A later patch will make us share this codepath to serialize into -webkit-linear-gradient() syntax. That syntax uses the same representation for points as unprefixed modern linear-gradient() (with box-side-or-corner keywords "top", "right", etc.), but it does *not* use the word "to". So we'd like to allow "to"-and-its-subsequent-space-character to be optional. Hence, this patch groups the space together with "to", rather than as a prefix on the next token, so that we can skip right to printing the point (without a leading space) when we add support for -webkit-linear-gradient() serialization. MozReview-Commit-ID: 5fCzx4NmpcC
011c86025a5b4056dd46d4c38de7379248207b74: Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 15:43:31 +0200 - rev 568064
Push 55746 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:41:39 +0000
Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian,walkingice Custom and web app tabs behave as any other externally launched URLs, that is pressing the back button closes not only the activity, but the tab as well when reaching the beginning of session history. Therefore, we should finish the activity in this case (just as the CustomTabsActivity already does), so the next launch runs through the onCreate code path and opens a new tab again. MozReview-Commit-ID: 14AhWkmb5O7
288610c6a31379328bb95987a2f89d106b7f5f4a: Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 18:26:45 +0200 - rev 568063
Push 55746 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:41:39 +0000
Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian,walkingice Differences to custom tabs: - We don't have to store the full intent, just storing the manifest path is enough. - Akin to the LauncherActivity we have to route the request to the correct WebAppActivity instance depending on the manifest path. We also have to modify the intent handling when GeckoApp is starting up - the intent handling of the GeckoApp + BrowserApp combo requires "nulling" out (by setting it to ACTION_MAIN) the current intent if it's not a fresh intent (e.g. the activity is recreated after having been destroyed or relaunched from the task switcher). For web apps on the other hand we want to keep the intent around even in those cases, as it contains state we need even later on. Additionally, we want to make use of GeckoApp's startup code for either selecting the tab from the intent or loading a new tab. Therefore we save the launch intent and restore it once GeckoApp's onCreate() has run. Note that this solution is not entirely correct either, because with this each onCreate() call will open a new tab, even when this is not necessary when only the activity (but not Firefox and Gecko as a whole) had been destroyed. This behaviour will be fixed as part of bug 1352997. This approach is also a bit different than the one chosen in bug 1351605 for custom tabs, which was independently developed in parallel. Bug 1352997 will unify this, too. MozReview-Commit-ID: 94uZ3c8CUVD
68280e4b9869fff72e110e04e77a83e6bbffe9c4: Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 09 Apr 2017 19:49:02 +0200 - rev 568062
Push 55746 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:41:39 +0000
Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian,walkingice This can happen if closing a tab (via the back button) simultaneously also triggered an activity switch (by selecting the parent tab). In that case the tab is closed, but formal selection of the new tab only completes after we've switched activities. At the moment activity switching might trigger an application-background/foreground cycle, which means we could hit the selected tab temporarily being undefined in Gecko. MozReview-Commit-ID: 6p4cOqj29HX
593fb1b0f2b74342989fd780916def66dc41e706: Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 23:10:51 +0200 - rev 568061
Push 55746 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:41:39 +0000
Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian,walkingice On tab selection, the Tabs instance now checks whether the type of the tab to be selected matches the currently running activity. If it doesn't, the tab switching is aborted and instead, an intent for the correct activity is sent. When the new activity launches, it finds that the intent also includes a tab ID, which means that instead of opening a new tab we retry the tab selection, which will then succeed now that we're in the correct activity. Because for custom tabs the launch intent can contain all sorts of customisations, we now have to save the intent when a custom tab is opened for the first time, so that later on, when switching e.g. from BrowserApp back to a custom tab we can use the correct intent to launch the custom tab activity. MozReview-Commit-ID: KWdkweKBocz
e9cfc32325ed733b7c6a25b0050129fd50a788b7: Bug 1351739 - Part 2 - Convert CustomTabsActivity to SafeIntents. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 14:09:36 +0200 - rev 568060
Push 55746 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:41:39 +0000
Bug 1351739 - Part 2 - Convert CustomTabsActivity to SafeIntents. r?sebastian,walkingice These are potentially untrusted external intents, so we should use SafeIntents for interacting with them. MozReview-Commit-ID: 3nmjg85wbr1
71fde2b613ede2bf8008a483a3ff055784d67b8e: Bug 1351739 - Part 1 - Track the currently active activity. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 11:22:12 +0200 - rev 568059
Push 55746 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:41:39 +0000
Bug 1351739 - Part 1 - Track the currently active activity. r?sebastian,walkingice Required because later on, we'll need to know if we're in the correct activity for a tab or need to switch activities. As a follow-up, we can later also hook up our current manual activity tracking from GeckoApplication to this (we most probably won't be able to get rid of the GeckoActivityStatus shenanigans, though). MozReview-Commit-ID: 5lZrAMsB9Gy
c0a909ecffcf920da6471fa4deb18d41343182d7: Bug 1351739 - Part 0 - Use INVALID_TAB_ID more. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 06 Apr 2017 21:30:55 +0200 - rev 568058
Push 55746 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:41:39 +0000
Bug 1351739 - Part 0 - Use INVALID_TAB_ID more. r?sebastian,walkingice -1 is probably not all that mysterious as far as magic numbers go, but still... MozReview-Commit-ID: zK3P6HeWzK
3ca8fac9c85377ab54d7fc6250acf7099d4fdff7: Bug 1351739 - Part -1 - Housekeeping. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 07 Apr 2017 20:51:41 +0200 - rev 568057
Push 55746 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:41:39 +0000
Bug 1351739 - Part -1 - Housekeeping. r?sebastian,walkingice MozReview-Commit-ID: Ev6jl4N3K0g
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip