Playing ogg video will not update page titles on other open tabs

VERIFIED FIXED in mozilla1.9.2a1

Status

()

Core
XPConnect
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: tchung, Assigned: mrbkap)

Tracking

({regression, verified1.9.1})

Trunk
mozilla1.9.2a1
regression, verified1.9.1
Points:
---
Bug Flags:
blocking1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090502 Minefield/3.6a1pre
Build Identifier: 

When a ogg video is playing, switching to another open tab will not update the page title of that tab.   The page of the ogg video persists across all other tabs.

Reproducible: Always

Steps to Reproduce:
1. install branch and trunk nightly
2. open a few different URLs (eg. cnn.com, msnbc.com, planet.mozilla.org)
3. open another tab with a ogg video (eg. URL above)
4. on the blizzard video demo site, play the first video in the list
5. as the video plays, navigate to the other tabs 
6. Verify the other tabs has the same page title as the video (eg. Minefield)
7. Verify stopping the video and going to other tabs, will show the responsive page title for that tab
Actual Results:  
Video playback page persists the page title across all tabs

Expected Results:  
Video playback page should not persist the page title across all tabs
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1a1611bb1063&tochange=e167d6ca2023
I tested this with two tabs, the first was the homepage and the second the URL with the video.
Keywords: regression
OS: Mac OS X → All
Hardware: x86 → All
It's also in Shiretoko.
Flags: blocking1.9.1?
OS: All → Mac OS X
Hardware: All → x86
Version: unspecified → Trunk
OS: Mac OS X → All
Hardware: x86 → All
Flags: blocking1.9.1? → blocking1.9.1+
Interesting. This seems to be focus related... If you switch tabs immediately after clicking play (or any other part of the video controls), the bug happens. If you click play, and then somewhere on the document outside the <video>, the window title is correctly updated.
Aha. So, the immediate problem is in tabbrowser.xul's updateCurrentBrowser()...

854                 var elem = this.mCurrentBrowser.focusedElement;
855                 if (elem instanceof HTMLElement || elem instanceof XULElement) {
856                   elem.blur();
857                 }

When blur() is called, it throws:

which ends up throwing: [Exception... "Unexpected error"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://browser/content/tabbrowser.xml :: updateCurrentBrowser :: line 853"  data: no]

I'm going to go out on a limb an assume this yet again has something to do with native anonymous content, but I didn't look into why the blur() fails. From the legends and rumors of focus code I've heard, I'm a little afraid. :-)

I suppose the simple fix would be to just wrap a try/catch around the call. That's enough to fix the title problem, but I notice there's one other side effect... After switching back to the tab with the video, the video controls don't fade back in. The video control <handler> never gets the event, so I assume focus is confused. If I click on the page content, that's enough to get things working again.
Enn: ideas? Should we bandaid this with a try/catch, or fix the underlying focus problem?
This is pretty bad, but it should be easy to at least work around for 1.9.1.
Assignee: nobody → dolske

Comment 7

9 years ago
Justin, the fix for this is likely to just do the else clause that calls nsIDOMWindowUtils::Focus(null) when the call to blur fails.
(Reporter)

Comment 8

9 years ago
Also, I noticed it only happens with video controls are shown and video is playing.  If you hide controls, yet still play the video with focus on the video, and switch tabs, the page titles are updated accordingly.
(Reporter)

Comment 9

9 years ago
More information here.  This seems to screw up any new tabs and the source of the page.   For example, if you open a new tab during video play, because the page title is retaining the video page data, it's also bringing up the viewsource for the video page instead of the content new page you opened.  

Further artifacts in this state, show if you try and visit a URL in the new page (with the video playing in the other tab), then the new url will open on both the current tab, AND the video tab (video stops, url launches)
Created attachment 377013 [details] [diff] [review]
Patch v.1

Enn: so, this makes the document title update correctly, but it doesn't help with the problem described at the end of comment 4. If I explicitly null out this.mCurrentBrowser.focusedElement, the latter issue is resolved as well.
Created attachment 377017 [details] [diff] [review]
Patch v.2

This fixes both problems, but I'm unsure of it's evilness.

Also nulled out commandDispatcher.focusedElement, since it looks like the 2 are supposed to be kept in sync, although I couldn't notice any difference without doing that... Nulling mCurrentBrowser.focusedElement is both necessary and sufficient to fix the observed problem.
Attachment #377013 - Attachment is obsolete: true
Attachment #377017 - Flags: review?(enndeakin)
Attachment #377017 - Attachment is patch: true
Attachment #377017 - Attachment mime type: application/octet-stream → text/plain
Attachment #377017 - Flags: review?(gavin.sharp)
You shouldn't set document.commandDispatcher.focusedElement, that actually tries to set focus. Falling back to the alternate nsIDOMWindowUtils.focus(null) call per Neil's comment 7 should also avoid the need to null out this.mCurrentBrowser.focusedElement, I think.
Attachment #377017 - Flags: review?(gavin.sharp)
Attachment #377017 - Flags: review?(enndeakin)
Attachment #377017 - Flags: review-
Well, the problem is that falling back to the else-block doesn't help -- see Patch v.1 and comment 10... The addition of a try/catch is enough to make the window tile update properly, but when you switch back to the video the controls don't see mouseover/mouseout events.
Oh, I see. Presumably the whatToFocus.focus() call is throwing when you switch back? That would explain why nulling out focusedElement would avoid it.
(Assignee)

Comment 15

9 years ago
This is *so* mine.
Assignee: dolske → mrbkap
Status: NEW → ASSIGNED
Component: Video/Audio → XPConnect
QA Contact: video.audio → xpconnect
(Assignee)

Comment 16

9 years ago
Created attachment 377638 [details] [diff] [review]
wip

Dolske tested this patch and it works. I need to clean it up and add some more comments tomorrow. Basically what's happening is that we have a SOW(XPCNW(element)). We resolve the 'blur' function on the element onto the SOW (which is an XPCNativeWrapped function), not wrapping it. We then call the function with 'this' being a SOW. XPC_NW_FunctionWrapper doesn't expect this and throws. The fix is to wrap native functions (not scripted functions, more on that tomorrow) in a SOW function wrapper that unwraps the SOW.
Attachment #377017 - Attachment is obsolete: true
(Assignee)

Comment 17

9 years ago
Created attachment 377793 [details] [diff] [review]
patch v1

Turned out to be comments only.
Attachment #377638 - Attachment is obsolete: true
Attachment #377793 - Flags: superreview?(jst)
Attachment #377793 - Flags: review?(jst)

Updated

9 years ago
Attachment #377793 - Flags: superreview?(jst)
Attachment #377793 - Flags: superreview+
Attachment #377793 - Flags: review?(jst)
Attachment #377793 - Flags: review+
Also, when the tab with the video is not the focused tab and I type an URL, the URL opens over the video in the inactive tab. :)
(Assignee)

Updated

9 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Blocks: 478580
Verified fixed on trunk and 1.9.1 with builds on all platforms like;

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090601 Minefield/3.6a1pre ID:20090601031227

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090601 Shiretoko/3.5pre ID:20090601031153
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.