u279076 Reporter
	Description • 9 years ago

When I click on a link on digg.com with e10s enabled I get two tabs with the same page.

1. Make sure e10s is enabled
2. Load digg.com
3. Click a link of the page
> Two tabs are opened to the same URL
4. Disable e10s and restart
5. Load digg.com and click the same link as in step 3
> One tab is opened to that URL

As near as I can tell this issue has always existed with e10s and is not a regression.

	Alice0775 White
	Comment 1 • 9 years ago

Open index.html and click link "The Color Of Disruption"

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 2 • 9 years ago

Hope it's cool if I steal this one, billm. Let me know if you'd like it back.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 3 • 9 years ago

Drilled this down to this bit of scripting on their site:

function v(e) {
    var r = 'http://api.digg.com/api/v3/redirect',
      i = $(this).closest(a),
      s = i.data('contentId'),
      o = i.data('position'),
      u = t.user.get('user_id'),
      f = n.get('frontend.auid'),
      l = i.data('source'),
      c = {
        url: this.href
      };
      s && (c.content_id = s),
      u ? c.user_id = u : f && (c.auid = f),
      l && (c.source = l),
      o != null && (c.position = o),
      navigator.mozApps && window.locationbar.visible === !1 && (c.platform = 1005, window.open([r,
      $.param(c)].join('?')));
      if (p === 'mobile') c.platform = 1005,
      window.location.href = [
        r,
        $.param(c)
      ].join('?');
       else {
        if (this.target !== '_blank') return;
        window.open([r,
        $.param(c)].join('?'))
      }
      return !1
}

In the line starting with navigator.mozApps, we also check to see if window.locationbar.visible is false - and if so, we do a window.open. Later on, we check to see if we're not on a mobile platform, and if so, we do a second window.open.

For some reason, with e10s, on digg, window.locationbar.visible is false. On other properties it's true. With e10s disabled, window.locationbar.visible is true on digg.

Drilling into why that is now.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 4 • 9 years ago

My mistake - it looks like window.locationbar.visible is _always_ false with e10s.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 5 • 9 years ago

The problem appears to be when the parent creates a TabParent, and sends the PBrowser constructor message down to the child. We send down some (extremely minimal) chrome flags at the same time, which the TabChild then stores.

The BarProps then queries TabChild for its chromeFlags value to determine whether or not things like window.locationbar.visible should be true. Because the chromeFlags that TabParent sent down was so minimal (it only ever sets CHROME_PRIVATE_LIFETIME or CHROME_PRIVATE_WINDOW), it can't provide the correct information.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 6 • 9 years ago

Bug 1194897 - Copy parent window chromeFlags when instantiating a new TabParent in the parent process. r?smaug

The parent window chromeFlags contain information that the content process
needs - for example, whether or not the location bar, menubar, status bar,
and personal toolbar are set to be visible.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 7 • 9 years ago

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

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 8 • 9 years ago

Comment on attachment 8663875 [details]
MozReview Request: Bug 1194897 - Copy parent window chromeFlags when instantiating a new TabParent in the parent process. r?smaug

Bug 1194897 - Copy parent window chromeFlags when instantiating a new TabParent in the parent process. r?smaug

The parent window chromeFlags contain information that the content process
needs - for example, whether or not the location bar, menubar, status bar,
and personal toolbar are set to be visible.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 9 • 9 years ago

Comment on attachment 8663875 [details]
MozReview Request: Bug 1194897 - Copy parent window chromeFlags when instantiating a new TabParent in the parent process. r?smaug

I wonder what we should do with the chromeFlags for the latter new TabParent call in the method (the one about apps).
Could you file a followup bug for that and CC me and kanru.

(If TabParent is allocated because of child side sending ctor, we get chrome flags from child side.)

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 10 • 9 years ago

Filed bug 1207628.

Thanks smaug!

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 11 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/a916f9351384809eb48e2c4e0fa5df38e212f437
Bug 1194897 - Copy parent window chromeFlags when instantiating a new TabParent in the parent process. r=smaug

	Carsten Book [:Tomcat]
	Comment 12 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/a916f9351384

	Mohammad Maruf Islam
	Comment 13 • 9 years ago

I have reproduced this bug with Firefox Nightly 43.0a1 (Build ID: 20150814030208) on 
windows 8.1 64-bit with the instructions from comment 0 .

Verified as fixed with Firefox Nightly 44.0a1 (Build ID: 20151021065025)

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0

	Nazir Ahmed Sabbir [:NaSb]
	Comment 14 • 9 years ago

Reproduced this bug on Nightly 43.0a1 (2015-08-14)  (Build ID: 20150814030208) in Linux,64 bit

This Bug is now verified as fixed on Latest Firefox Nightly 44.0a1 (2015-10-25)

Build ID: 20151025030428
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0

As it is also verified on Windows (Comment 13), Marking it as verified!

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 15 • 8 years ago
bugnotes

http://people.mozilla.org/~mconley2/bugnotes/bug-1194897.html