1173866 - DOM fullscreen broken in e10s (DOM fullscreen fails on the other than the first tab)

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Tom S. (please needinfo tschuster)]

In e10s mode pressing the fullscreen mode button on YouTube just produces a short flash. This is on Linux Mint with the HTML5 player.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Is this a recent regression?

Comment 2

[Tom S. (please needinfo tschuster)]

Yes, but it also seems to be specific to my profile, because it works in a clean profile. I however already disabled all my addons in my main profile and it still doesn't work. It's also apparently not specific to YouTube's fullscreen usage, because http://davidwalsh.name/demo/fullscreen.php doesn't work either.

Comment 3

[Tom S. (please needinfo tschuster)]

Attachment: about:support

Comment 4

[Tom S. (please needinfo tschuster)]

I narrowed it down and the range looks really promising!
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d17480aae980&tochange=10d47ad00e7a

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

I agree it might be a regression of bug 1161802 since that bug makes entering fullscreen asynchronous and adds additional check because of that.

But if you cannot reproduce that with a clean profile, I guess it would be hard to identify where the actual problem is.

Could you provide messages in the Web Console and the Browser Console when you try entering fullscreen? Hopefully they can provide some useful information.

Comment 6

[Alice0775 White]

[Tracking Requested - why for this release]: regression

The problem happens on the other than first tab.

Steps To Reproduce
1. Start Nightly with newly created profile
2. Switch to second tab. If not exist, open new tab
3. Open http://ie.microsoft.com/testdrive/Graphics/VideoFormatSupport/Default.html
        or attached
4. Click fullscreen button

Actual Results:
Fullscreen fails. No error in the Browser Console.

If open the page in the first tab, it works as expected

Pushlog
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d17480aae980&tochange=10d47ad00e7a

Regressed by: Bug 1161802

Comment 7

[Alice0775 White]

Attachment: DOMFullcreen.html

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

Thanks for the steps to reproduce. I can reproduce it now. It is indeed a serious problem.

Comment 10

[Xidorn Quan [:xidorn] UTC+10]

Attachment: patch

The problem is because, in bug 1161802 patch 7, we check whether the original target is a browser by checking whether its tag name is "xul:browser". However, for tabs other than the first one, the tag name of browser is just "browser", not "xul:browser". This patch use a different, hopefully more reliable way to distinguish <browser> from other elements.

Comment 11

[Richard Newman [:rnewman]]

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

This landed with the wrong bug number.

Comment 12

[Xidorn Quan [:xidorn] UTC+10]

Oops... sorry about that...

Comment 14

[wig_2006]

Thanks you very much to fix DOM fullscreen broken.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #10)
> However, for tabs other than the first one, the tag name of
> browser is just "browser", not "xul:browser".
Oops, never use tagName, but namespaceURI + localName.

Comment 16

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Olli Pettay [:smaug] (for generic DOM reviews, you may want to look for other reviewers too ;)) from comment #15)
> (In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #10)
> > However, for tabs other than the first one, the tag name of
> > browser is just "browser", not "xul:browser".
> Oops, never use tagName, but namespaceURI + localName.

Ah... I didn't know that. Thanks.

Then I checked the document of namespaceURI, and saw the example was about checking whether an element is an XUL browser https://developer.mozilla.org/en-US/docs/Web/API/Node/namespaceURI :)

I wonder whether I should back to this way.

Comment 17

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Adding a tracking flag for FF41. Setting qe-verify:+ to ensure QE verifies this. This is also noteworthy from a E10s verification point of view.

Comment 18

[Vasilica Tamas, QA [:vtamas]]

I was able to reproduce this issue on Firefox 41.0a1 (2015-06-11) under Ubuntu 14.04 32-bit.

Verified fixed on Firefox 41.0a1 (2015-06-23) and Firefox 43.0a1 (2015-09-06) using Ubuntu 14.04 32-bit, Mac OS X 10.10.5 and Windows 7 64-bit.