bd5ad14fec03c6a4024291c2435c0f76781f8959: Bug 1359548: Fix incorrectly specified ABIs in js-ctypes declaration in migration code; r?Gijs draft
Aaron Klotz <aklotz@mozilla.com> - Tue, 25 Apr 2017 13:02:32 -0600 - rev 568109
Push 55759 by aklotz@mozilla.com at Tue, 25 Apr 2017 19:03:00 +0000
Bug 1359548: Fix incorrectly specified ABIs in js-ctypes declaration in migration code; r?Gijs MozReview-Commit-ID: LH1MOyuXVos
daee028bbe21e64c92219dc56065868ca60e2f28: Bug 1358552: Fix incorrect ABI specification in js-ctypes declarations; r?froydnj draft
Aaron Klotz <aklotz@mozilla.com> - Tue, 25 Apr 2017 13:00:23 -0600 - rev 568108
Push 55759 by aklotz@mozilla.com at Tue, 25 Apr 2017 19:03:00 +0000
Bug 1358552: Fix incorrect ABI specification in js-ctypes declarations; r?froydnj MozReview-Commit-ID: JuNNtbNC5pe
74dc5696a13e7273480ac780d4636507494c5aa4: Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 5: FontFaceRule. r=xidorn draft
Fernando Jimenez Moreno <ferjmoreno@gmail.com> - Tue, 25 Apr 2017 16:24:40 +0200 - rev 568107
Push 55758 by ferjmoreno@gmail.com at Tue, 25 Apr 2017 19:02:18 +0000
Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 5: FontFaceRule. r=xidorn MozReview-Commit-ID: InyYKJhWAbv
f28a88190c542b4128ec77c849c02971445fa71b: Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 4: NamespaceRule. r=xidorn draft
Fernando Jimenez Moreno <ferjmoreno@gmail.com> - Tue, 25 Apr 2017 16:24:39 +0200 - rev 568106
Push 55758 by ferjmoreno@gmail.com at Tue, 25 Apr 2017 19:02:18 +0000
Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 4: NamespaceRule. r=xidorn MozReview-Commit-ID: FSRr7fXJ7Wp
65835a856532f3f3a69e5bbeb2de4147ddd62c77: Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 3: PageRule. r=xidorn draft
Fernando Jimenez Moreno <ferjmoreno@gmail.com> - Tue, 25 Apr 2017 16:24:39 +0200 - rev 568105
Push 55758 by ferjmoreno@gmail.com at Tue, 25 Apr 2017 19:02:18 +0000
Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 3: PageRule. r=xidorn MozReview-Commit-ID: 8Mnz51icFXz
f96e307e9b4cb263aa8b5d45e02eb88862c9d20c: Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 2: Introduce RULE_LOCATION_GETTERS. r=xidorn draft
Fernando Jimenez Moreno <ferjmoreno@gmail.com> - Tue, 25 Apr 2017 16:24:39 +0200 - rev 568104
Push 55758 by ferjmoreno@gmail.com at Tue, 25 Apr 2017 19:02:18 +0000
Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 2: Introduce RULE_LOCATION_GETTERS. r=xidorn MozReview-Commit-ID: 4NU4Y5gp6hz
f827711413cede62b5653dac69d9024e03ec0f96: Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 1: StyleRule. r=xidorn draft
Fernando Jimenez Moreno <ferjmoreno@gmail.com> - Tue, 25 Apr 2017 16:24:39 +0200 - rev 568103
Push 55758 by ferjmoreno@gmail.com at Tue, 25 Apr 2017 19:02:18 +0000
Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 1: StyleRule. r=xidorn MozReview-Commit-ID: 6ODvvX5JX7O
5ca7e8e04d73ffa3126f91162cc96f5f7ee1964f: Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 0: Set stylesheet line offset. r=xidorn draft
Fernando Jimenez Moreno <ferjmoreno@gmail.com> - Tue, 25 Apr 2017 21:01:45 +0200 - rev 568102
Push 55758 by ferjmoreno@gmail.com at Tue, 25 Apr 2017 19:02:18 +0000
Bug 1350175 - stylo: Support getting line / column number of CSS rules. Part 0: Set stylesheet line offset. r=xidorn MozReview-Commit-ID: A5vDWyMKeDI
e90779ca57f548ef5b5d4bccee71c1ca94225d3e: bug 1357457 - Report non-overlapping Input Responses to Telemetry. r?masayuki data-r=bsmedberg draft
Chris H-C <chutten@mozilla.com> - Wed, 19 Apr 2017 15:53:30 -0400 - rev 568101
Push 55757 by bmo:chutten@mozilla.com at Tue, 25 Apr 2017 19:02:10 +0000
bug 1357457 - Report non-overlapping Input Responses to Telemetry. r?masayuki data-r=bsmedberg Say there's a single lag event, a GC or a busy loop, during which the user types several characters. Is this one (lag) event? Several (input) events? We have INPUT_EVENT_RESPONSE_MS which will accumulate several lagged events in this case. However, that is more of an indication of how users use Firefox than how good we've been at eliminating sources of lag. INPUT_EVENT_RESPONSE_COALESCED_MS records the coalesced time spend waiting for responses to input events. So in this case it will record one value for the entire duration of the lag. MozReview-Commit-ID: H5rYnhwF0q3
7e74b711b5d47d74b6e6dac55d11310e45e41a62: Bug 1352618 - Enable network de-prioritization based on tracking annotations. r?cpeterson draft
Francois Marier <francois@mozilla.com> - Tue, 11 Apr 2017 13:21:26 -0700 - rev 568100
Push 55756 by fmarier@mozilla.com at Tue, 25 Apr 2017 19:01:21 +0000
Bug 1352618 - Enable network de-prioritization based on tracking annotations. r?cpeterson MozReview-Commit-ID: 7YJSatboA0
d76e4fdc30d34cc4385ffc8d97c3a128e1ccf633: Bug 1351805 part 3 - Refresh the remote devices list on Married/Engaged states. r?Grisha draft
Edouard Oger <eoger@fastmail.com> - Wed, 19 Apr 2017 17:45:49 -0400 - rev 568099
Push 55755 by bmo:eoger@fastmail.com at Tue, 25 Apr 2017 18:58:59 +0000
Bug 1351805 part 3 - Refresh the remote devices list on Married/Engaged states. r?Grisha MozReview-Commit-ID: 1Ktbtlzc1fI
c1def579d6adc28464aafc43a03ff05ded9e06f4: Bug 1351805 part 2 - Add remote devices to the Browser Provider. r?Grisha draft
Edouard Oger <eoger@fastmail.com> - Fri, 07 Apr 2017 12:24:46 -0400 - rev 568098
Push 55755 by bmo:eoger@fastmail.com at Tue, 25 Apr 2017 18:58:59 +0000
Bug 1351805 part 2 - Add remote devices to the Browser Provider. r?Grisha MozReview-Commit-ID: 9yGU2Gy6mX1
cc231b8525d27cbc5929449f9e0b82916bbcfbfc: Bug 1351805 part 1 - Create a org.mozilla.gecko.fxa.devices package. r?Grisha draft
Edouard Oger <eoger@fastmail.com> - Fri, 07 Apr 2017 11:56:38 -0400 - rev 568097
Push 55755 by bmo:eoger@fastmail.com at Tue, 25 Apr 2017 18:58:59 +0000
Bug 1351805 part 1 - Create a org.mozilla.gecko.fxa.devices package. r?Grisha MozReview-Commit-ID: FjJmRiHlqEg
30608ce18d1c9f43d23a2f773902188205982988: Bug 1334278 - have FormatStackDump return UniqueChars; r?froydnj draft
Tom Tromey <tom@tromey.com> - Fri, 21 Apr 2017 12:47:06 -0600 - rev 568096
Push 55754 by bmo:ttromey@mozilla.com at Tue, 25 Apr 2017 18:56:59 +0000
Bug 1334278 - have FormatStackDump return UniqueChars; r?froydnj Change FormatStackDump to return UniqueChars and fix up the users. This removes a bit more manual memory management. MozReview-Commit-ID: 60GBgeS4rzg
66ce8488d7e4360fe23c003f22536e338de3e11a: Bug 1334278 - change JS_smprintf to return UniqueChars; r?froydnj draft
Tom Tromey <tom@tromey.com> - Fri, 03 Mar 2017 15:10:11 -0700 - rev 568095
Push 55754 by bmo:ttromey@mozilla.com at Tue, 25 Apr 2017 18:56:59 +0000
Bug 1334278 - change JS_smprintf to return UniqueChars; r?froydnj This changes JS_smprintf to return UniqueChars, rather than relying on manual memory management. MozReview-Commit-ID: ENjQJODYdD1
447585356ac10d7646467120f7b92681cab114dc: Bug 1352997 - Part 7 - Don't switch activities if we're closing a tab while exiting the activity. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 14 Apr 2017 19:58:09 +0200 - rev 568094
Push 55753 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:55:36 +0000
Bug 1352997 - Part 7 - Don't switch activities if we're closing a tab while exiting the activity. r?sebastian,walkingice Closing the currently selected tab will select another tab, which can trigger an activity switch if the tab types differ. We don't want that if we're about to close the activity, as that'll bring that activity into the foreground instead of simply walking back along the activity history stack. To give an example: Without this patch, closing the last custom tab will select a normal browsing tab, which will trigger an activity switch, so instead of returning to the user's previous activity, pressing back will send us to BrowserApp. There's one additional catch: If we change our onDone() behaviour and no longer finish() the SingleTabActivity when exiting (in order to avoid a costly restart of Gecko should the user return to us soon), this means that the activity that has just been exited could be brought back into the foreground via the onResume() codepath. In that case the mLastActiveGeckoApp-check won't be triggered if no other GeckoApp-based activity was active in the meantime, so we wouldn't reselect/reopen the activity's desired tab, but instead display the tab that was selected when closing the previous tab. Therefore, we track this via an additional flag that is set for this case. MozReview-Commit-ID: 3jOvBXQUrfo
a9ad5426acf72a1f12a2a94a3b5e187a6eee2fe3: Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 04 Apr 2017 21:50:33 +0200 - rev 568093
Push 55753 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:55:36 +0000
Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. r?sebastian,walkingice Web Apps are single task activities, but Android's task switcher will only ever return the intent that originally created the activity and will never ever update its stored intent for subsequent launches via onNewIntent, so we have to do this ourselves. Additionally, web apps have some additional logic when being launched via a new intent that checks whether the currently loaded page matches the scope of the web app intent and then resets it if necessary. We now hook up this logic to the new SingleTabActivity wiring. MozReview-Commit-ID: 9bo4gXbfPNg
fb18d18c2a59538a7f9f1336ea4cd42a18a92edf: Bug 1352997 - Part 5 - Implement common behaviour for custom tabs/web apps and switch over the former. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:19:32 +0200 - rev 568092
Push 55753 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:55:36 +0000
Bug 1352997 - Part 5 - Implement common behaviour for custom tabs/web apps and switch over the former. r?sebastian,walkingice This implements the common behaviour for restoring the correct tab when switching to/from custom tab and web app activities. Unlike our normal UI, those activities are basically single tab activities, that is each activity is linked to a certain Gecko tab, with no facilities (bugs aside) for the user to directly load/select a different tab within that activity. Therefore, here we basically update the selected tab only when the activity is starting up and initially creating its new (or, especially once tab type switching will be implemented, taking over an existing) content tab. When subsequently restoring, we then check whether the tab is still available. If it is, we select it, if not, we fall back to opening a new tab based on the available intent data. This also means that we no longer have to finish() the activity on closing so the activity state (finished) matches the tab (closed), which means that we no longer have to prematurely kill Gecko as a side effect of that. MozReview-Commit-ID: KjFz1qrqWLy
12e18ae21d77028e8d8a4a8a0aabbbc3ec4552b5: Bug 1352997 - Part 4 - Remember the tab selected by session restoring if somebody other than BrowserApp is starting up first. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:15:19 +0200 - rev 568091
Push 55753 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:55:36 +0000
Bug 1352997 - Part 4 - Remember the tab selected by session restoring if somebody other than BrowserApp is starting up first. r?sebastian,walkingice The first activity to run triggers Gecko startup and therefore session restore. Since the selected tab stored in the session file is only of interest for BrowserApp, we need to store it somewhere safe if some other activity (e.g. custom tab/web app) starts up first. This is because currently everything needs to share the same Gecko browser window, so those other activities selecting a tab of their own when starting up will necessarily override session restore's tab selection. MozReview-Commit-ID: 9GwTDbzgWF9
62ee02b835c1e1360b8c31acdbcc0a260e7f6a5a: Bug 1352997 - Part 3 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 22:55:10 +0200 - rev 568090
Push 55753 by mozilla@buttercookie.de at Tue, 25 Apr 2017 18:55:36 +0000
Bug 1352997 - Part 3 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian,walkingice Currently, we basically take a snapshot of the currently selected tab when pausing an activity and then later re-select that tab ID when switching back from another activity within our application. In practice, this doesn't seem entirely fool-proof, so when switching between our normal UI (BrowserApp) and custom tabs or web apps we can eventually end up with the wrong tab being selected in the wrong activity. In this part, we'll rip out the current code and replace it by a new implementation for BrowserApp - following parts will then cover custom tabs and web apps. As BrowserApp is our normal tabbed browsing interface, we can simply track all tab switches for BROWSING-type tabs as they happen, which ensures that our data is always up-to-date. Because tab IDs remain unique only within the same application session and are reused if we're terminated and then later restart, we need to take additional precautions to make sure we're really selecting the correct tab object - the savedInstanceState can carry even across (OOM-)kills. Therefore we now additionally also store and compare the current per-session UUID to make sure that the tab we're trying to select is really the same one it was when the activity was last running. For BrowserApp caring about this is less important because on a full startup, the selection behaviour will be overridden by session restore anyway (although we can still hit it if only BrowserApp gets destroyed while Gecko keeps running, or if BrowserApp is launched after some other activity has already loaded Gecko), but it'll be quite relevant for web apps and custom tabs which don't have that benefit. As it stands, this patch temporarily breaks behaviour around activity restoring for custom tabs/web apps, but tearing the old implementation out in one go was easier and the patch needs to be split somewhere. MozReview-Commit-ID: I0Tq9XZGvpV
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip