1177152 - Add Tracking Protection tour entry point to about:privatebrowsing

Status: VERIFIED FIXED

(Firefox :: Private Browsing, defect, P1)

Description

[Matthew N. [:MattN]]

When a user opens a new private window, we should introduce the new tracking protection functionality and provide an entry point to start the tour (possibly just opening a new tab).

The copy will likely appear on every about:privatebrowsing tab and not be conditional.

Comment 1

[:Paolo Amadini]

Starting exploring this - will figure out at which point we will need the final text.

Comment 2

[:Paolo Amadini]

Attachment: MozReview Request: Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing.

Comment 3

[:Paolo Amadini]

Attachment: Normal window size similar to mockup

Comment 4

[:Paolo Amadini]

Attachment: Window size close to full screen

Comment 5

[:Paolo Amadini]

Attachment: Small window size

Comment 6

[:Paolo Amadini]

This is a preliminary version with the final copy from bug 1179850, still missing the combined shield and mask image, as well as some guidance on how to handle the space in a fullscreen window.

We'll probably want some simple tests to check that the links work.

Comment 7

[:Paolo Amadini]

Actually, the request from the user experience team is that the page should be visible as an alternative to the current page even if the tour was already taken. After a few releases, another version of the page will replace both this new design and the current design.

To allow landing this patch in Nightly without affecting the current users, we'll make the new design conditional on whether the Tracking Protection UI is enabled.

We've also determined that for the moment it's fine for the tour button to link the current Tracking Protection support page.

Comment 8

[Ash Grigas]

SVG for icon of mask and shield: http://cl.ly/1n0j3e2X3g1W

Comment 9

[Ash Grigas]

Paolo - here is the spec for the built in page. Also for reference is the onboarding flow. Let me know if you have any questions. For the responsive spec - not sure if you want exact pixel margins or percentages of page. I used your screenshots to map out intended margins but not sure if they are to scale or not so try to get close and post screen caps and we can revise as needed. 
https://www.dropbox.com/sh/nhh6z6nr9gx0mng/AAAPYeSlfVZADtNGeGqIh1pwa?dl=0

Comment 10

[:Paolo Amadini]

Comment on attachment 8632117 [details]
MozReview Request: Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

Comment 11

[:Paolo Amadini]

Attachment: Latest screenshot

Okay, so I've changed the margins and font sizes in the patch to use the pixel values from the specification. Often I had to approximate the values to keep into account the distance between the text baseline and the bottom margin of the paragraph, but the result should be quite similar to the mockup.

The margins of the text paragraphs are now aligned as requested. The text has a maximum width rather than a fixed margin to improve readability with large window widths. This is in fact what the current page does.

The overall result looks ready for Nightly to me, I think we should file follow-ups if there are specific issues to address.

One of the issues is maybe the font choice for this page. Apparently Fira Sans is not distributed with Desktop builds, it's only used in Firefox OS and the website. The possibility I explored here is to be consistent with the other in-content pages and use the same font, which for OS X is Lucida Grande UI, the one visible in the screenshot.

Comment 12

[Ash Grigas]

(In reply to :Paolo Amadini from comment #11)
> Created attachment 8632583 [details]
> Latest screenshot
> 
> Okay, so I've changed the margins and font sizes in the patch to use the
> pixel values from the specification. Often I had to approximate the values
> to keep into account the distance between the text baseline and the bottom
> margin of the paragraph, but the result should be quite similar to the
> mockup.
> 
> The margins of the text paragraphs are now aligned as requested. The text
> has a maximum width rather than a fixed margin to improve readability with
> large window widths. This is in fact what the current page does.
> 
> The overall result looks ready for Nightly to me, I think we should file
> follow-ups if there are specific issues to address.
> 
> One of the issues is maybe the font choice for this page. Apparently Fira
> Sans is not distributed with Desktop builds, it's only used in Firefox OS
> and the website. The possibility I explored here is to be consistent with
> the other in-content pages and use the same font, which for OS X is Lucida
> Grande UI, the one visible in the screenshot.

The Hello tour uses Fira - is that because their page is implemented differently?

Comment 13

[:Paolo Amadini]

(In reply to agrigas from comment #12)
> The Hello tour uses Fira - is that because their page is implemented
> differently?

I think that's because the tour is entirely hosted remotely on the website.

Comment 14

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8632117 [details]
MozReview Request: Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

https://reviewboard.mozilla.org/r/12999/#review11821

LGTM but the patch didn't apply anymore. Would like to take a look and play around before signing it off.

::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.js:10
(Diff revision 2)
> -var stringBundle = Cc["@mozilla.org/intl/stringbundle;1"].getService(Ci.nsIStringBundleService)
> -                                                         .createBundle("chrome://browser/locale/aboutPrivateBrowsing.properties");
> +var stringBundle = Services.strings.createBundle(
> +                     "chrome://browser/locale/aboutPrivateBrowsing.properties");

Nit: use "let" while you're at it.

::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.css:135
(Diff revision 2)
> +#tourFooter,
> +#tourLearnMore {
> +  font-size: 12px;
> +}

Shouldn't we use a relative font-size here?

::: browser/locales/en-US/chrome/browser/aboutPrivateBrowsing.dtd:25
(Diff revision 2)
> +<!ENTITY trackingProtection.description        "Tracking Protection will block content that tracks your browsing activity so you don’t have to worry about it being shared across websites.">

Looks like that should be "don't" instead of "don’t"? That's what the other labels use at least.

::: browser/themes/shared/mask-and-shield.svg:1
(Diff revision 2)
> +<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="179" height="88" viewBox="0 0 179 88">

Please add:

<?xml version="1.0" encoding="utf-8"?>
<!-- This Source Code Form is subject to the terms of the Mozilla Public
   - License, v. 2.0. If a copy of the MPL was not distributed with this
   - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->

::: browser/components/privatebrowsing/test/browser/browser_privatebrowsing_about.js:27
(Diff revision 2)
> +  win.gBrowser.contentWindow.history.back();

Guess we want gBrowser.goBack() instead of accessing the contentWindow here.

Comment 15

[Tim Taubert [:ttaubert] (inactive)]

https://reviewboard.mozilla.org/r/12999/#review11825

::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.css:100
(Diff revision 2)
> +  font-size: 38px;

Same about the relative font-size here.

::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.css:105
(Diff revision 2)
> +  font-size: 24px;

... and here.

Comment 16

[:Paolo Amadini]

(In reply to Tim Taubert [:ttaubert] from comment #14)
> Shouldn't we use a relative font-size here?

It used to be relative but got changed as noted in comment 11.

Comment 17

[:Paolo Amadini]

Comment on attachment 8632117 [details]
MozReview Request: Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

Comment 18

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8632117 [details]
MozReview Request: Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

https://reviewboard.mozilla.org/r/12999/#review11831

Sorry, this still fails to apply for me locally.

Comment 19

[:Paolo Amadini]

(In reply to Tim Taubert [:ttaubert] from comment #18)
> Sorry, this still fails to apply for me locally.

It's a mozreview changeset, so you should be able to pull it using its revision ID, then rebase on top of whatever changeset you want? It's based on top of fx-team at present.

Comment 20

[Tim Taubert [:ttaubert] (inactive)]

I have to download a patch because I'm not using hg. And that patch doesn't apply unfortunately.

Comment 21

[:Paolo Amadini]

It's based on top of fx-team, so you should be able to apply it cleanly there, or resolve the conflicts manually (likely in the manifest files).

Comment 22

[:Paolo Amadini]

Comment on attachment 8632117 [details]
MozReview Request: Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

Comment 23

[Ash Grigas]

(In reply to agrigas from comment #12)
> (In reply to :Paolo Amadini from comment #11)
> > Created attachment 8632583 [details]
> > Latest screenshot
> > 
> > Okay, so I've changed the margins and font sizes in the patch to use the
> > pixel values from the specification. Often I had to approximate the values
> > to keep into account the distance between the text baseline and the bottom
> > margin of the paragraph, but the result should be quite similar to the
> > mockup.
> > 
> > The margins of the text paragraphs are now aligned as requested. The text
> > has a maximum width rather than a fixed margin to improve readability with
> > large window widths. This is in fact what the current page does.
> > 
> > The overall result looks ready for Nightly to me, I think we should file
> > follow-ups if there are specific issues to address.
> > 
> > One of the issues is maybe the font choice for this page. Apparently Fira
> > Sans is not distributed with Desktop builds, it's only used in Firefox OS
> > and the website. The possibility I explored here is to be consistent with
> > the other in-content pages and use the same font, which for OS X is Lucida
> > Grande UI, the one visible in the screenshot.
> 
> The Hello tour uses Fira - is that because their page is implemented
> differently?

The link colors look different for Privacy Preferences and Learn more. Can we make them the same?

Comment 24

[:Paolo Amadini]

(In reply to agrigas from comment #23)
> The link colors look different for Privacy Preferences and Learn more. Can
> we make them the same?

Updated, will appear in the next revision of the patch.

Comment 25

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8632117 [details]
MozReview Request: Bug 1177152 - Add Tracking Protection tour entry point to about:privatebrowsing. r=ttaubert

https://reviewboard.mozilla.org/r/12999/#review11843

::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.js:15
(Diff revision 4)
> +  useTour = Services.prefs.getBoolPref("privacy.trackingprotection.ui.enabled");

That's not the right pref. It controls whether we show the "enable global TP" checkbox. Should probably use 'privacy.trackingprotection.pbmode.enabled'. We also wouldn't have to check whether that pref is available so we can remove the try/catch.

::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.css:117
(Diff revision 4)
> +  height: 40px;

This shouldn't be needed.

::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.css:78
(Diff revision 4)
> +  padding: 0 31px;

Looks like we don't need this.

::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.css:86
(Diff revision 4)
> +#tourTop {

I think this needs a max-height of ... maybe 300px? With a tall window this moves way too much to the center. Do we also want a min-height so that the logo doesn't get too close to the top? Do we want to give it a static height?

Comment 26

[:Paolo Amadini]

(In reply to Tim Taubert [:ttaubert] from comment #25)
> Should probably use 'privacy.trackingprotection.pbmode.enabled'.

Hm, that would mean that disabling the feature from the Privacy Preferences would disable the "see what's new" version of "about:privatebrowsing", reverting to the current page.

Aislinn, is this what we want?

Using the other about:config preference was a way to defer the activation of the new page in Nightly until the tour is ready, and provide a way to disable it, but we could revisit this.

> ::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.css:78
> (Diff revision 4)
> > +  padding: 0 31px;
> 
> Looks like we don't need this.

It's the horizontal margin from the exterior of the page, as requested.

> I think this needs a max-height of ... maybe 300px? With a tall window this
> moves way too much to the center. Do we also want a min-height so that the
> logo doesn't get too close to the top? Do we want to give it a static height?

Hm, I find there's too much space on the bottom if the separation line between the green area and the rest of the page isn't roughly central. Aislinn, any opinion about how that separation line should move?

Comment 27

[Ash Grigas]

(In reply to :Paolo Amadini from comment #26)
> (In reply to Tim Taubert [:ttaubert] from comment #25)
> > Should probably use 'privacy.trackingprotection.pbmode.enabled'.
> 
> Hm, that would mean that disabling the feature from the Privacy Preferences
> would disable the "see what's new" version of "about:privatebrowsing",
> reverting to the current page.
> 
> Aislinn, is this what we want?
> 
> Using the other about:config preference was a way to defer the activation of
> the new page in Nightly until the tour is ready, and provide a way to
> disable it, but we could revisit this.
> 
> > ::: browser/components/privatebrowsing/content/aboutPrivateBrowsing.css:78
> > (Diff revision 4)
> > > +  padding: 0 31px;
> > 
> > Looks like we don't need this.
> 
> It's the horizontal margin from the exterior of the page, as requested.
> 
> > I think this needs a max-height of ... maybe 300px? With a tall window this
> > moves way too much to the center. Do we also want a min-height so that the
> > logo doesn't get too close to the top? Do we want to give it a static height?
> 
> Hm, I find there's too much space on the bottom if the separation line
> between the green area and the rest of the page isn't roughly central.
> Aislinn, any opinion about how that separation line should move?

I'm ok leaving the tour accessible if someone turns of TP since the tour isn't conditional to the preference but rather is shown for a set duration of time.

For the auto-resizing of the window, can we try to maintain the general ratio we have at the default window size which always has half green and half white and the content sitting in the middle of each half? If you post screen shots I can give more guidance or we can chat in standup.

Comment 28

[:Paolo Amadini]

(In reply to agrigas from comment #27)
> I'm ok leaving the tour accessible if someone turns of TP since the tour
> isn't conditional to the preference but rather is shown for a set duration
> of time.

Then, Tim, then we can overload "privacy.trackingprotection.ui.enabled" for now, and make the new version unconditional when we ride the trains (that is when we switch the value in bug 1175606) or use a different preference and flip it as part of bug 1175606.

Note that after the duration of time Aislinn mentions, we'll will not go back to the old version but we'll use a new design.

> For the auto-resizing of the window, can we try to maintain the general
> ratio we have at the default window size which always has half green and
> half white and the content sitting in the middle of each half? If you post
> screen shots I can give more guidance or we can chat in standup.

That's what the current patch does, I'll keep it this way.

Comment 29

[:Paolo Amadini]

(In both cases I'll make a note in bug 1175606.)

Comment 30

[Tim Taubert [:ttaubert] (inactive)]

SGTM.

Comment 31

[Matthew N. [:MattN]]

(In reply to agrigas from comment #27)
> (In reply to :Paolo Amadini from comment #26)
> > (In reply to Tim Taubert [:ttaubert] from comment #25)
> > > Should probably use 'privacy.trackingprotection.pbmode.enabled'.
> > 
> > Hm, that would mean that disabling the feature from the Privacy Preferences
> > would disable the "see what's new" version of "about:privatebrowsing",
> > reverting to the current page.
> > 
> > Aislinn, is this what we want?
> 
> I'm ok leaving the tour accessible if someone turns of[sic] TP since the tour
> isn't conditional to the preference but rather is shown for a set duration
> of time.

If TP in PB is off then the tour is going to be confusing for all 3 steps for a few reasons:
* The tour will be referring to things that aren't happening (blocking of content),
* Step 1 panel won't be pointing to the shield icon.
* IIRC the TP section in step 3 won't be visible.

It seems like the tour content should adapt to whether TP is enabled or not if we do this. This is technically possible and easy if we want it.

Comment 32

[Ash Grigas]

(In reply to Matthew N. [:MattN] from comment #31)
> (In reply to agrigas from comment #27)
> > (In reply to :Paolo Amadini from comment #26)
> > > (In reply to Tim Taubert [:ttaubert] from comment #25)
> > > > Should probably use 'privacy.trackingprotection.pbmode.enabled'.
> > > 
> > > Hm, that would mean that disabling the feature from the Privacy Preferences
> > > would disable the "see what's new" version of "about:privatebrowsing",
> > > reverting to the current page.
> > > 
> > > Aislinn, is this what we want?
> > 
> > I'm ok leaving the tour accessible if someone turns of[sic] TP since the tour
> > isn't conditional to the preference but rather is shown for a set duration
> > of time.
> 
> If TP in PB is off then the tour is going to be confusing for all 3 steps
> for a few reasons:
> * The tour will be referring to things that aren't happening (blocking of
> content),
> * Step 1 panel won't be pointing to the shield icon.
> * IIRC the TP section in step 3 won't be visible.
> 
> It seems like the tour content should adapt to whether TP is enabled or not
> if we do this. This is technically possible and easy if we want it.

So to clarify:
1) the tour doesn't get triggered by default - user has to click 'Take Tour' in which they're in a simulated context anyways not a real page experience
2) for step #1 I thought the shield is showing because we load fake trackers on the page?
3) the second tour entry point from a link/direct url bar will never be triggered if TP is disabled since the shield would never show

Are my assumptions inaccurate? If that's not the case, let me sync up with Javaun on how important it is to surface the tour on disable before we decide to create yet another flow. Not sure how it is 'easy' to create new states for each onboarding step...

Comment 33

[Ash Grigas]

(In reply to agrigas from comment #32)
> (In reply to Matthew N. [:MattN] from comment #31)
> > (In reply to agrigas from comment #27)
> > > (In reply to :Paolo Amadini from comment #26)
> > > > (In reply to Tim Taubert [:ttaubert] from comment #25)
> > > > > Should probably use 'privacy.trackingprotection.pbmode.enabled'.
> > > > 
> > > > Hm, that would mean that disabling the feature from the Privacy Preferences
> > > > would disable the "see what's new" version of "about:privatebrowsing",
> > > > reverting to the current page.
> > > > 
> > > > Aislinn, is this what we want?
> > > 
> > > I'm ok leaving the tour accessible if someone turns of[sic] TP since the tour
> > > isn't conditional to the preference but rather is shown for a set duration
> > > of time.
> > 
> > If TP in PB is off then the tour is going to be confusing for all 3 steps
> > for a few reasons:
> > * The tour will be referring to things that aren't happening (blocking of
> > content),
> > * Step 1 panel won't be pointing to the shield icon.
> > * IIRC the TP section in step 3 won't be visible.
> > 
> > It seems like the tour content should adapt to whether TP is enabled or not
> > if we do this. This is technically possible and easy if we want it.
> 
> So to clarify:
> 1) the tour doesn't get triggered by default - user has to click 'Take Tour'
> in which they're in a simulated context anyways not a real page experience
> 2) for step #1 I thought the shield is showing because we load fake trackers
> on the page?
> 3) the second tour entry point from a link/direct url bar will never be
> triggered if TP is disabled since the shield would never show
> 
> Are my assumptions inaccurate? If that's not the case, let me sync up with
> Javaun on how important it is to surface the tour on disable before we
> decide to create yet another flow. Not sure how it is 'easy' to create new
> states for each onboarding step...

Synced up with Javaun - and we think changing the built in page to this:https://www.dropbox.com/s/tg3ux7iss856k7a/TP-disabled-built-in-page?dl=0

reflects that it is off and disables to in-context tour entry point.

Comment 34

[Matthew N. [:MattN]]

(In reply to agrigas from comment #32)
> (In reply to Matthew N. [:MattN] from comment #31)
> > (In reply to agrigas from comment #27)
> > > (In reply to :Paolo Amadini from comment #26)
> > > > (In reply to Tim Taubert [:ttaubert] from comment #25)
> > > > > Should probably use 'privacy.trackingprotection.pbmode.enabled'.
> > > > 
> > > > Hm, that would mean that disabling the feature from the Privacy Preferences
> > > > would disable the "see what's new" version of "about:privatebrowsing",
> > > > reverting to the current page.
> > > > 
> > > > Aislinn, is this what we want?
> > > 
> > > I'm ok leaving the tour accessible if someone turns of[sic] TP since the tour
> > > isn't conditional to the preference but rather is shown for a set duration
> > > of time.
> > 
> > If TP in PB is off then the tour is going to be confusing for all 3 steps
> > for a few reasons:
> > * The tour will be referring to things that aren't happening (blocking of
> > content),
> > * Step 1 panel won't be pointing to the shield icon.
> > * IIRC the TP section in step 3 won't be visible.
> > 
> > It seems like the tour content should adapt to whether TP is enabled or not
> > if we do this. This is technically possible and easy if we want it.
> 
> So to clarify:
> 1) the tour doesn't get triggered by default - user has to click 'Take Tour'
> in which they're in a simulated context anyways not a real page experience

Right, but if TP is off the simulated environment isn't going to block content if we implement like a real site so users can get the real experience of disabling it for the site.

> 2) for step #1 I thought the shield is showing because we load fake trackers
> on the page?

The shield won't show if TP is off though.

> 3) the second tour entry point from a link/direct url bar will never be
> triggered if TP is disabled since the shield would never show

I'm not sure what this is in reply to but it doesn't address my third point that the TP section isn't going to show up in the control center for step 3 if TP is off.

> Not sure how it is 'easy' to create new states for each onboarding step...

I meant "technically possible" and "technically easy".

Comment 35

[Ash Grigas]

(In reply to Matthew N. [:MattN] from comment #34)
> (In reply to agrigas from comment #32)
> > (In reply to Matthew N. [:MattN] from comment #31)
> > > (In reply to agrigas from comment #27)
> > > > (In reply to :Paolo Amadini from comment #26)
> > > > > (In reply to Tim Taubert [:ttaubert] from comment #25)
> > > > > > Should probably use 'privacy.trackingprotection.pbmode.enabled'.
> > > > > 
> > > > > Hm, that would mean that disabling the feature from the Privacy Preferences
> > > > > would disable the "see what's new" version of "about:privatebrowsing",
> > > > > reverting to the current page.
> > > > > 
> > > > > Aislinn, is this what we want?
> > > > 
> > > > I'm ok leaving the tour accessible if someone turns of[sic] TP since the tour
> > > > isn't conditional to the preference but rather is shown for a set duration
> > > > of time.
> > > 
> > > If TP in PB is off then the tour is going to be confusing for all 3 steps
> > > for a few reasons:
> > > * The tour will be referring to things that aren't happening (blocking of
> > > content),
> > > * Step 1 panel won't be pointing to the shield icon.
> > > * IIRC the TP section in step 3 won't be visible.
> > > 
> > > It seems like the tour content should adapt to whether TP is enabled or not
> > > if we do this. This is technically possible and easy if we want it.
> > 
> > So to clarify:
> > 1) the tour doesn't get triggered by default - user has to click 'Take Tour'
> > in which they're in a simulated context anyways not a real page experience
> 
> Right, but if TP is off the simulated environment isn't going to block
> content if we implement like a real site so users can get the real
> experience of disabling it for the site.
> 
> > 2) for step #1 I thought the shield is showing because we load fake trackers
> > on the page?
> 
> The shield won't show if TP is off though.
> 
> > 3) the second tour entry point from a link/direct url bar will never be
> > triggered if TP is disabled since the shield would never show
> 
> I'm not sure what this is in reply to but it doesn't address my third point
> that the TP section isn't going to show up in the control center for step 3
> if TP is off.
> 
> > Not sure how it is 'easy' to create new states for each onboarding step...
> 
> I meant "technically possible" and "technically easy".

See above mock for proposed solution. And for point #1 above - we haven't decided to implement it like a real site with users disabling it so let's not make assumptions we are going to do that until we discuss it as a team and re-open that issue.

Comment 36

[:Paolo Amadini]

I'll land this patch and use bug 1177156 to implement the additional requirement.

Comment 37

[:Paolo Amadini]

https://hg.mozilla.org/integration/fx-team/rev/9798359363a0

Comment 38

[Tim Taubert [:ttaubert] (inactive)]

Sorry, had to back out due to bustage (and couldn't find you on IRC):

TEST-UNEXPECTED-FAIL | browser/components/privatebrowsing/test/browser/browser_privatebrowsing_about.js | Uncaught exception - TypeError: content.document.getElementById(...) is null
TEST-UNEXPECTED-FAIL | browser/components/privatebrowsing/test/browser/browser_privatebrowsing_about.js | Found an unexpected browser window at the end of test run - expected PASS

https://hg.mozilla.org/integration/fx-team/rev/6d7c3381a951

Comment 39

[:Paolo Amadini]

Looks like a Linux only failure, maybe timing related. We've worked a lot on that code since the last try run, will look into it again after rebasing on top of the other bustage fixes from today.

Comment 40

[:Paolo Amadini]

Looked at results too early: the issue is actually with e10s and the goBack() call. For the sake of expediency I've just removed the goBack and moved the test case using it to the last position, let's see if this works.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2e75210cc781

Comment 41

[:Paolo Amadini]

https://hg.mozilla.org/integration/fx-team/rev/6dcdde80d196

Comment 42

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/6dcdde80d196

Comment 43

[Matt Wobensmith [:mwobensmith][:matt:]]

Verified on Nightly Fx42.0a1, 2015-07-27.