2553f996afefe4276aef86c61ec99e6b7fd62242: Bug 1359603 - Set text combined bit on the context for Servo as well. r=heycam draft
J. Ryan Stinnett <jryans@gmail.com> - Mon, 24 Apr 2017 16:13:36 -0500 - rev 568932
Push 56024 by bmo:jryans@gmail.com at Wed, 26 Apr 2017 19:05:54 +0000
Bug 1359603 - Set text combined bit on the context for Servo as well. r=heycam We want to set style bits on `nsStyleContext` regardless of which engine is providing the style source. The moves the bit set up to `SetStyleBits` which runs for both sources. MozReview-Commit-ID: 8N6oUyxz1Xs
73fa2a10106b7cdfb8dc3d8072934f34abaef4e2: Bug 1359603 - Port text-combine-upright writing mode fixup to Servo. r=heycam draft
J. Ryan Stinnett <jryans@gmail.com> - Mon, 24 Apr 2017 16:04:15 -0500 - rev 568931
Push 56024 by bmo:jryans@gmail.com at Wed, 26 Apr 2017 19:05:54 +0000
Bug 1359603 - Port text-combine-upright writing mode fixup to Servo. r=heycam Ports the Gecko fixup for text-combine-upright writing mode to Servo. In addition, this passes the current pseudo element (if any) down to the cascade for use during the fixup process. MozReview-Commit-ID: BkHd4AvSsOt
3f40c6ad0fdd4d6928d108d6644e3c6a64f860db: Bug 1359603 - Correct typo about pseudo_element macros. r=heycam draft
J. Ryan Stinnett <jryans@gmail.com> - Fri, 21 Apr 2017 11:46:01 -0500 - rev 568930
Push 56024 by bmo:jryans@gmail.com at Wed, 26 Apr 2017 19:05:54 +0000
Bug 1359603 - Correct typo about pseudo_element macros. r=heycam MozReview-Commit-ID: 3PDBeOdsX4D
c73a1e1841c05c90ba57a72e2465670d1857d7c3: Bug 1359603 - Tweak style adjust ordering to better match Gecko. r=heycam draft
J. Ryan Stinnett <jryans@gmail.com> - Wed, 26 Apr 2017 11:30:05 -0500 - rev 568929
Push 56023 by bmo:jryans@gmail.com at Wed, 26 Apr 2017 19:03:45 +0000
Bug 1359603 - Tweak style adjust ordering to better match Gecko. r=heycam To ease comparison between Gecko's `nsStyleContext::ApplyStyleFixups` and the Servo equivalent, move them into a similar ordering. MozReview-Commit-ID: GV89pbzA8IH
e5943a9393e5e8514b914d674430c08df7bc77eb: Bug 1346493 - Extra spec comments for style adjustments. r=heycam draft
J. Ryan Stinnett <jryans@gmail.com> - Wed, 26 Apr 2017 10:41:07 -0500 - rev 568928
Push 56023 by bmo:jryans@gmail.com at Wed, 26 Apr 2017 19:03:45 +0000
Bug 1346493 - Extra spec comments for style adjustments. r=heycam MozReview-Commit-ID: J6qxBpQ43Ax
3ea87d936329c85d0ff423a83797a24349e9225c: Bug 1346493 - Set text combined bit on the context for Servo as well. r=heycam draft
J. Ryan Stinnett <jryans@gmail.com> - Mon, 24 Apr 2017 16:13:36 -0500 - rev 568927
Push 56023 by bmo:jryans@gmail.com at Wed, 26 Apr 2017 19:03:45 +0000
Bug 1346493 - Set text combined bit on the context for Servo as well. r=heycam We want to set style bits on `nsStyleContext` regardless of which engine is providing the style source. The moves the bit set up to `SetStyleBits` which runs for both sources. MozReview-Commit-ID: 8N6oUyxz1Xs
fafb5b07d2ff14cb26e916ce79483c662d3b155c: Bug 1346493 - Port text-combine-upright writing mode fixup to Servo. r=heycam draft
J. Ryan Stinnett <jryans@gmail.com> - Mon, 24 Apr 2017 16:04:15 -0500 - rev 568926
Push 56023 by bmo:jryans@gmail.com at Wed, 26 Apr 2017 19:03:45 +0000
Bug 1346493 - Port text-combine-upright writing mode fixup to Servo. r=heycam Ports the Gecko fixup for text-combine-upright writing mode to Servo. In addition, this passes the current pseudo element (if any) down to the cascade for use during the fixup process. MozReview-Commit-ID: BkHd4AvSsOt
7ac9906c3cb36273994f396ff77e7fffd22c6804: Bug 1346493 - Correct typo about pseudo_element macros. r=heycam draft
J. Ryan Stinnett <jryans@gmail.com> - Fri, 21 Apr 2017 11:46:01 -0500 - rev 568925
Push 56023 by bmo:jryans@gmail.com at Wed, 26 Apr 2017 19:03:45 +0000
Bug 1346493 - Correct typo about pseudo_element macros. r=heycam MozReview-Commit-ID: 3PDBeOdsX4D
c62c47a45746355f1bb5ed1b17ae4c7309e56eb6: Bug 1358224 - pt 2 - change to RTP stream id filtering on simulcast mochitests. r=drno draft
Michael Froman <mfroman@mozilla.com> - Wed, 26 Apr 2017 10:51:00 -0500 - rev 568924
Push 56022 by bmo:mfroman@nostrum.com at Wed, 26 Apr 2017 18:48:19 +0000
Bug 1358224 - pt 2 - change to RTP stream id filtering on simulcast mochitests. r=drno The simulcast mochitests setup the receiving PeerConnection to receive simulcast video streams which Firefox doesn't really support. Without a test media server, this is about the best we can do and still test simulcast. Unfortunately the two simulcast streams arriving with different ssrcs (as expect) exercises code we have to deal with some services switching ssrcs midstream. In the tests, this causes intermittent failures because the test is waiting to receive a certain ssrc, and the receiving VideoConduit has switched to the other ssrc. This change adds the ability to filter on RID at the MediaPipeline level, which we can setup prior to media flowing. This avoids the ssrc switching issue since the VideoConduit only receives one ssrc until we change the RID filter to the second RID. At that point, the VideoConduit sees a new ssrc and the switching code works as intended. The modified mochitests setup the RTP stream id header extension, and then filter on each of the RTP stream ids in turn. MozReview-Commit-ID: KApfaxMX8rl
0a03c2222193a1d07909ee534876166fd7019f85: Bug 1358224 - pt 1 - addRIDExtension and addRIDFilter chrome-only API for RID (RTP Stream Id) filtering of receive tracks. r=qDot draft
Michael Froman <mfroman@mozilla.com> - Wed, 26 Apr 2017 10:01:07 -0500 - rev 568923
Push 56022 by bmo:mfroman@nostrum.com at Wed, 26 Apr 2017 18:48:19 +0000
Bug 1358224 - pt 1 - addRIDExtension and addRIDFilter chrome-only API for RID (RTP Stream Id) filtering of receive tracks. r=qDot The simulcast mochitests exhibit an intermittent failure due to ssrc-based filtering that can be solved by filtering by RID. The RTP header parser used in MediaPipeline also needs to have the RID RTP header extension specified in order for it to properly parse the RTP header and allow filtering on RID. MozReview-Commit-ID: E54HCGLVYDk
bd62085e145a2d1bd324e41fc9d1ad5f969943a6: Bug 1356415 - move findCssSelector to toolkit draft
Julian Descottes <jdescottes@mozilla.com> - Wed, 26 Apr 2017 15:30:36 +0200 - rev 568922
Push 56021 by jdescottes@mozilla.com at Wed, 26 Apr 2017 18:40:12 +0000
Bug 1356415 - move findCssSelector to toolkit MozReview-Commit-ID: 2KOeij1oJnT
befea92ccce91faaa8fefc4c5adec9a3e5f381b8: Bug 1353857 - Include the tab ID when notifying about leaving/entering a web app's scope. r?daleharvey,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 17 Apr 2017 16:37:58 +0200 - rev 568921
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +0000
Bug 1353857 - Include the tab ID when notifying about leaving/entering a web app's scope. r?daleharvey,walkingice We only want to process the AppEntered/Left message if it actually concerns our currently displayed tab. MozReview-Commit-ID: EJ8RzRzDNAz
8ab255628f9bb0a159538b2bd3fb43bdfcffc05b: Bug 1351808 - Part 2 - Exclude non-standard tab types from session store. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 13:43:09 +0200 - rev 568920
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +0000
Bug 1351808 - Part 2 - Exclude non-standard tab types from session store. r?sebastian Restoring anything other than normal browsing tabs (e.g. custom tabs, web apps) is more involved because those tabs - don't appear in our normal tabs UI - are opened in separate activities - when we're starting up, Android's task switcher might or might not still have available task entries corresponding to such tabs from the last session Therefore, for now, the session store will simply exclude those kinds of tabs from being saved in the session store data. Instead of a real restore, if the corresponding tab has been closed or Gecko stopped running, we just recreate the custom tab/web app based on the stored Activity intent data we have available (bug 1352997). Tab zombification while Gecko is running however remains fully supported, as we continue collecting session history data for all tab types, even if we don't necessarily save it to disk. Because custom tabs/web apps currently still share a common Gecko browser window with normal tabs, we also have to modify our selected tab tracking logic accordingly, so that selecting one of these special tab types doesn't overwrite the last selected normal browsing tab. To that effect, we now track the selected tab *ID* in memory and only convert that to a tab index when writing the data to disk. As the ID remains stable while Gecko is running, this makes tracking changes for a sub-group of tabs only easier, as we don't have to watch out for closing tabs of *any* kind affecting the tab index of everything behind them. Bug 1346008#c3 has some preliminary ideas on how session restoring for custom tabs/web apps could be made to work. MozReview-Commit-ID: 1q5Jtv0DKrE
b9de096d2e678fa6dd7329f30879cc6efa385c21: Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 14:18:23 +0200 - rev 568919
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +0000
Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian MozReview-Commit-ID: BzqieZVi7h4
2416d92b0470b6aa6edee2cb224eff9f110061a7: BrowserApp startup tab selection debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 22:59:16 +0200 - rev 568918
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +0000
BrowserApp startup tab selection debug logging MozReview-Commit-ID: 79QnUF1Edg3
ef23bdfd3719f44f080df1bea14ff8d34c3ca26e: debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:16:31 +0200 - rev 568917
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +0000
debug logging MozReview-Commit-ID: FoUd4cklLKs
d29fae387705a1a18986728a0080b4a4216ac914: 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 568916
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +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
ced475dfb0dcd2f8187b54fc1049bc43941f87b9: 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 568915
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +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
ece3f3bc33756d3e80784e000e5146aa1c444556: 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 568914
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +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
e901ceeb6b2e4bce9230e1f995c60036f1a03b25: 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 568913
Push 56020 by mozilla@buttercookie.de at Wed, 26 Apr 2017 18:35:14 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip