Last Comment Bug 689106 - No video controls when directly viewing a video
: No video controls when directly viewing a video
Status: VERIFIED FIXED
[fixed-in-fx-team][qa+][qa!:9][qa!:10]
: regression, verified-aurora, verified-beta
Product: Toolkit
Classification: Components
Component: Video/Audio Controls (show other bugs)
: 9 Branch
: All All
: -- normal (vote)
: mozilla9
Assigned To: Jared Wein [:jaws] (please needinfo? me)
:
: Jared Wein [:jaws] (please needinfo? me)
Mentors:
: 689915 (view as bug list)
Depends on:
Blocks: 472942 678465 690208
  Show dependency treegraph
 
Reported: 2011-09-26 01:01 PDT by Justin Dolske [:Dolske]
Modified: 2013-12-27 14:19 PST (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
Backout of revision 379147b5215f (3.36 KB, patch)
2011-09-28 17:52 PDT, Jared Wein [:jaws] (please needinfo? me)
jonas: review+
asa: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Justin Dolske [:Dolske] 2011-09-26 01:01:24 PDT
Limi caught this in bug 376997 comment 59. When viewing an OGG file directly, the video controls are not shown. Regression from bug 472942? Slightly surprising we'd miss this during development, but maybe this is an unrelated change from elsewhere? Regression range unknown. We should probably add a test to play a video in this condition.

Tested with 9/23 Nightly on OS X.

EG: load http://videos-cdn.mozilla.net/serv/air_mozilla/07272011_brownbag.ogg

I see the following in the error console upon loading the video:

Error: Permission denied for <http://videos-cdn.mozilla.net> to get property Object.dynamicControls
Source File: chrome://global/content/bindings/videocontrols.xml
Line: 348

Error: this.Utils is undefined
Source File: chrome://global/content/bindings/videocontrols.xml
Line: 234

The latter (with different line numbers) repeats on every mouseover/out. I saw similar errors in the past due to XPConnect bugs (xbl in content like this tends to trigger weird cases), might need to call in mrbkap/bholley for a consult.
Comment 1 Chris Pearce (:cpearce) 2011-09-26 01:21:17 PDT
Regression is between:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110922 Firefox/9.0a1 [Good]
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110924 Firefox/9.0a1 [Bad]
Comment 2 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-09-26 09:08:26 PDT
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4495e1f795c2&tochange=c71229984353

Bug 660233 looks like a suspect here.
Comment 3 Jared Wein [:jaws] (please needinfo? me) 2011-09-26 14:53:13 PDT
bz, mrbkap: I'm unfamiliar with the area of code for bug 660233. Can either of you confirm that this regression was introduced by that patch?
Comment 4 Jared Wein [:jaws] (please needinfo? me) 2011-09-26 18:44:26 PDT
I'm having trouble reproducing this bug now with a new build from mozilla-central.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2011-09-26 22:12:54 PDT
> Can either of you confirm that this regression was introduced by that patch?

That patch would affect any code that examines the nodePrincipal, baseURIObject, or documentURIObject properties from inside an XBL binding attached to content.

Do video controls do that?  I don't recall seeing anything like that in the videocontrols code...
Comment 6 Jared Wein [:jaws] (please needinfo? me) 2011-09-27 10:29:50 PDT
In today's nightly on Windows (9/27), the problem seems to have reappeared. Yesterday when I noticed the bug wasn't there I was using Mac OSX.
Comment 7 Jared Wein [:jaws] (please needinfo? me) 2011-09-27 10:49:56 PDT
(In reply to Boris Zbarsky (:bz) from comment #5)
> > Can either of you confirm that this regression was introduced by that patch?
> 
> That patch would affect any code that examines the nodePrincipal,
> baseURIObject, or documentURIObject properties from inside an XBL binding
> attached to content.
> 
> Do video controls do that?  I don't recall seeing anything like that in the
> videocontrols code...

Neither do I. Perhaps that is not the patch that caused the regression?
Comment 8 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-09-27 10:53:34 PDT
Well, I was sort of guessing based on what looked like scary xpconnect changes.  Somebody could actually bisect here ;-)
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-09-27 11:05:06 PDT
Indeed.  Whoever can reproduce the bug and build should just bisect....
Comment 10 Chris Pearce (:cpearce) 2011-09-27 12:41:32 PDT
The merge across to aurora (for Firefox 9) contains this bug, we must land out fix on Aurora as well as central.
Comment 11 Jared Wein [:jaws] (please needinfo? me) 2011-09-27 17:17:34 PDT
I ran an hg bisect between these two changesets with no luck:
20110922030907
http://hg.mozilla.org/mozilla-central/rev/4495e1f795c2

20110924030858
http://hg.mozilla.org/mozilla-central/rev/c71229984353


From talking with :cpearce, it seems to only be reproducible on profiles that have been heavily used.
Comment 12 Jared Wein [:jaws] (please needinfo? me) 2011-09-27 17:25:41 PDT
I forgot to mention above that my attempt to hg bisect was using a relatively clean profile.
Comment 13 Matthew Gregan [:kinetik] 2011-09-28 06:51:41 PDT
*** Bug 689915 has been marked as a duplicate of this bug. ***
Comment 14 Jared Wein [:jaws] (please needinfo? me) 2011-09-28 15:46:20 PDT
I reran hg bisect with a heavily used profile and narrowed down the cause of this bug to this patch:

The first bad revision is:
changeset:   77337:379147b5215f
user:        Gabor Krizsanits <gkrizsanits@mozilla.com>
date:        Thu Sep 22 17:35:25 2011 +0100
summary:     Bug 678465 - 'document-element-inserted' doesn't fire on ImageDocument; r=sicking
Comment 15 Jared Wein [:jaws] (please needinfo? me) 2011-09-28 16:56:17 PDT
I have also narrowed down the reason why a "heavily used" profile was needed.

This bug is only reproducible if a Jetpack extension is installed and enabled. If the Jetpack extensions are disabled then this bug can't be reproduced.
Comment 16 Jared Wein [:jaws] (please needinfo? me) 2011-09-28 17:52:37 PDT
Created attachment 563255 [details] [diff] [review]
Backout of revision 379147b5215f

Backing out revision 379147b5215f fixes this regression.

Pushed to try: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=1abbc725d51a
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2011-09-28 18:19:44 PDT
So... it sounds like jetpack does something that screws us over here.  Is it maybe looking for document-element-inserted and then messing with the DOM such that the binding gets instantiated too early or something?
Comment 18 Dave Townsend [:mossop] 2011-09-28 18:27:03 PDT
Alex, do you have any ideas about comment 17?
Comment 19 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-09-28 19:36:08 PDT
Comment on attachment 563255 [details] [diff] [review]
Backout of revision 379147b5215f

Review of attachment 563255 [details] [diff] [review]:
-----------------------------------------------------------------

r=me
Comment 20 Mozilla RelEng Bot 2011-09-28 23:10:50 PDT
Try run for 1abbc725d51a is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=1abbc725d51a
Results (out of 164 total builds):
    success: 148
    warnings: 6
    failure: 10
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jwein@mozilla.com-1abbc725d51a
Comment 21 Gabor Krizsanits [:krizsa :gabor] 2011-09-29 02:59:08 PDT
With bugzilla tweaks 1.11 turned on the bug can be reproduced, when it's disabled the bug is gone.
Comment 22 Alexandre Poirot [:ochameau] 2011-09-29 04:11:20 PDT
Ok, so we are breaking video controls by simply listening to 'document-element-inserted' event! Nothing more is needed. But as this event seems to be only used by jetpack ... It means that any jetpack addon using page-mod will enable this bug.
I don't understand why bug 678465 is involved as I thought the related patch was limited to ImageDocument. And videos are opened a regular HTMLDocument.
Gabor: any idea?

To reproduce this bug, simply execute this in your JS console:
Components.classes["@mozilla.org/observer-service;1"]  
          .getService(Components.interfaces.nsIObserverService)
          .addObserver({ observer: function () {} }, "document-element-inserted", false);
Comment 23 Gabor Krizsanits [:krizsa :gabor] 2011-09-29 04:17:56 PDT
(In reply to Alexandre Poirot (:ochameau) from comment #22)

> I don't understand why bug 678465 is involved as I thought the related patch
> was limited to ImageDocument. And videos are opened a regular HTMLDocument.
> Gabor: any idea?

It is implemented for MultimediaDocument, ImageDocument is a subclass of it.
Comment 24 Gabor Krizsanits [:krizsa :gabor] 2011-09-29 09:39:50 PDT
This is really strange... (In reply to Boris Zbarsky (:bz) from comment #17)
> So... it sounds like jetpack does something that screws us over here.  Is it
> maybe looking for document-element-inserted and then messing with the DOM
> such that the binding gets instantiated too early or something?

Can an early nsXPCWrappedJSClass::CallMethod with the document as an argument mess up something? Like binding the document to some wrapper it should not? I've been trying to debug this today but only got more confused to be honest...
Comment 25 Jared Wein [:jaws] (please needinfo? me) 2011-09-29 10:56:19 PDT
Simply backing out the patch for Bug 678465 seems to break JetPack builds on WinDebug (not sure why it passed on other platforms).

The Android failures don't appear to stem from this backout (but are odd nonetheless).
Comment 26 Boris Zbarsky [:bz] (still a bit busy) 2011-09-29 21:53:03 PDT
Hmm.  Comment 22 is interesting...  An empty listener really shouldn't have much of an effect here, apart from creating the JS wrapper for the document a bit earlier.  But that shouldn't usually cause problems.

In the missing video controls case, does the videocontrols binding fail to attach correctly?  Or does it attach but not initialize correctly, perhaps?  Or does everything look good with it?
Comment 27 Gabor Krizsanits [:krizsa :gabor] 2011-09-30 08:09:11 PDT
(In reply to Boris Zbarsky (:bz) from comment #26)
> In the missing video controls case, does the videocontrols binding fail to
> attach correctly?  Or does it attach but not initialize correctly, perhaps? 
> Or does everything look good with it?

As far as I can tell everything seems to be alright with the binding/init.
Comment 28 Boris Zbarsky [:bz] (still a bit busy) 2011-09-30 08:41:49 PDT
OK, and the video itself is there, just not the controls?
Comment 29 Gabor Krizsanits [:krizsa :gabor] 2011-09-30 09:08:33 PDT
Exactly. The this.Utils (videocontrols.xml:234) undefined in comment 1, is from the <constructor> ... How can that be undefined? I'm trying to find that piece of code, that supposed to set Utils property on the js object.
Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2011-09-30 09:16:39 PDT
Oh, there's an actual useful JS error here!  I missed that somehow.

Utils is set up as a field on the videocontrols.  Running the field script presumably triggers the first extension from comment 0.

So the real question is why that first exception is thrown...
Comment 31 Gabor Krizsanits [:krizsa :gabor] 2011-09-30 10:02:48 PDT
The weird thing is that in the example in Comment 22, there is a typo ('observer:' instead of 'observe:'). If I run the example script with the typo prior to visit the .ogg video, I get different results. In that case an exception is thrown when the observer is trying to call observe, and then the videocontrols give another kind of error. 
Error: attempt to run compile-and-go script on a cleared scope
Source File: chrome://global/content/bindings/videocontrols.xml
Line: 241

So it looks like that call by the observer has some effect here, I just don't understand how can that happen.
Is it possible that the nsXPCWrappedJSClass::CallMethod from the observer messes up something on the jscontext of the document? Like setting an exception on it or something?
Comment 32 Boris Zbarsky [:bz] (still a bit busy) 2011-09-30 10:36:07 PDT
It's all possible, but pretty unlikely....
Comment 33 Gabor Krizsanits [:krizsa :gabor] 2011-10-03 06:14:09 PDT
(In reply to Boris Zbarsky (:bz) from comment #30)

> So the real question is why that first exception is thrown...

Object.dynamicControls

For some reason the parent of the Object (this.Utils) is a ChromeWindow when the exception is thrown, but it should be a regular Window (without the observer it is a regular window). I have not yet figured out why is that the case.
Comment 34 Boris Zbarsky [:bz] (still a bit busy) 2011-10-03 07:07:20 PDT
So (mixing JS and C++ a bit here), JS_GetParent(this.Utils) is the ChromeWindow?  What compartment is this.Utils allocated in?
Comment 35 Jared Wein [:jaws] (please needinfo? me) 2011-10-03 14:25:23 PDT
I noticed today that the video controls appear to work when viewing the video in full screen mode.
Comment 36 Jared Wein [:jaws] (please needinfo? me) 2011-10-03 20:50:43 PDT
https://hg.mozilla.org/integration/fx-team/rev/00060b8e57f7

I have backed out the offending patch since the introduction of the |document-element-inserted| event was introduced by this patch and didn't exist previously for MediaDocument while it also introduced a regression on our video controls.
Comment 37 Boris Zbarsky [:bz] (still a bit busy) 2011-10-03 21:08:10 PDT
There's still an underlying issue here.  The situation described in comment 33 is incredibly scary and should NOT be happening no matter what happened with that notification.
Comment 38 Jared Wein [:jaws] (please needinfo? me) 2011-10-04 09:10:15 PDT
http://hg.mozilla.org/mozilla-central/rev/00060b8e57f7

(In reply to Boris Zbarsky (:bz) from comment #37)
> There's still an underlying issue here.  The situation described in comment
> 33 is incredibly scary and should NOT be happening no matter what happened
> with that notification.

Yeah I agree. Should we keep this bug open or file a follow-up bug?
Comment 39 Gabor Krizsanits [:krizsa :gabor] 2011-10-04 09:15:49 PDT
(In reply to Boris Zbarsky (:bz) from comment #34)
> So (mixing JS and C++ a bit here), JS_GetParent(this.Utils) is the
> ChromeWindow?  What compartment is this.Utils allocated in?

Utils is not even allocated in the error case, it's field install is failing. That Object that has a ChromeWindow parent is something else from the frame... So here it goes:
At some point nsXBLProtoImplField::InstallField is called for Utils. It calls JS_EvaluateUCScriptForPrincipalsVersion with the text that describes the Utils object in the xml files. At this point everything seems to be alright (scope/url...). Even js::ExecuteKernel seem to have everything fine. But then in jsinterp.cpp Interpret (:5011), in BEGIN_CASE(JSOP_GETTER) BEGIN_CASE(JSOP_SETTER) after JSOP_INITPROP case gs_get_lval pulls out that Object (regs.sp[i-1]) that has ChromeWindow as its parent... Then CheckObjectAccess fails, Utils will be set to undefined etc... So it seems to me that something with the frames is messed up.

call stack: 

 	xul.dll!nsScriptSecurityManager::CheckObjectAccess(JSContext * cx=0x0607a0e8, JSObject * obj=0x066ef4c0, int id=186279520, JSAccessMode mode=JSACC_WATCH, JS::Value * vp=0x0043ae70)  Line 603	C++
 	mozjs.dll!js::CheckAccess(JSContext * cx=0x0607a0e8, JSObject * obj=0x066ef4c0, int id=186279520, JSAccessMode mode=JSACC_WATCH, JS::Value * vp=0x0043ae70, unsigned int * attrsp=0x0043ae84)  Line 6682 + 0x1d bytes	C++
 	mozjs.dll!js::Interpret(JSContext * cx=0x0607a0e8, js::StackFrame * entryFrame=0x03d100f0, js::InterpMode interpMode=JSINTERP_NORMAL)  Line 5037 + 0x27 bytes	C++
 	mozjs.dll!js::RunScript(JSContext * cx=0x0607a0e8, JSScript * script=0x0b1bf790, js::StackFrame * fp=0x03d100f0)  Line 614 + 0xf bytes	C++
 	mozjs.dll!js::ExecuteKernel(JSContext * cx=0x0607a0e8, JSScript * script=0x0b1bf790, JSObject & scopeChain={...}, const JS::Value & thisv={...}, js::ExecuteType type=EXECUTE_GLOBAL, js::StackFrame * evalInFrame=0x00000000, JS::Value * result=0x0043b8b0)  Line 814 + 0x11 bytes	C++
 	mozjs.dll!js::Execute(JSContext * cx=0x0607a0e8, JSScript * script=0x0b1bf790, JSObject & scopeChainArg={...}, JS::Value * rval=0x0043b8b0)  Line 853 + 0x1d bytes	C++
 	mozjs.dll!EvaluateUCScriptForPrincipalsCommon(JSContext * cx=0x0607a0e8, JSObject * obj=0x0663db30, JSPrincipals * principals=0x0451b39c, const wchar_t * chars=0x080e57a8, unsigned int length=38122, const char * filename=0x0622a920, unsigned int lineno=240, JS::Value * rval=0x0043b8b0, JSVersion compileVersion=JSVERSION_ECMA_5)  Line 4924 + 0x15 bytes	C++
 	mozjs.dll!JS_EvaluateUCScriptForPrincipalsVersion(JSContext * cx=0x0607a0e8, JSObject * obj=0x0663db30, JSPrincipals * principals=0x0451b39c, const wchar_t * chars=0x080e57a8, unsigned int length=38122, const char * filename=0x0622a920, unsigned int lineno=240, JS::Value * rval=0x0043b8b0, JSVersion version=JSVERSION_ECMA_5)  Line 4936 + 0x2e bytes	C++
>	xul.dll!nsJSContext::EvaluateStringWithValue(const nsAString_internal & aScript={...}, void * aScopeObject=0x0663db30, nsIPrincipal * aPrincipal=0x0451b398, const char * aURL=0x0622a920, unsigned int aLineNo=240, unsigned int aVersion=185, void * aRetValue=0x0043b914, int * aIsUndefined=0x0043b990)  Line 1269 + 0x46 bytes	C++
 	xul.dll!nsXBLProtoImplField::InstallField(nsIScriptContext * aContext=0x06077ed8, JSObject * aBoundNode=0x0663db30, nsIPrincipal * aPrincipal=0x0451b398, nsIURI * aBindingDocURI=0x064df0b0, int * aDidInstall=0x0043ba24)  Line 135 + 0x6f bytes	C++
 	xul.dll!XBLResolve(JSContext * cx=0x0607a0e8, JSObject * obj=0x043755b8, int id=76240448, unsigned int flags=1, JSObject * * objp=0x0043ba68)  Line 202 + 0x32 bytes	C++
 	mozjs.dll!CallResolveOp(JSContext * cx=0x0607a0e8, JSObject * start=0x0663db30, JSObject * obj=0x043755b8, int id=76240448, unsigned int flags=1, JSObject * * objp=0x0043bb0c, JSProperty * * propp=0x0043bb00, bool * recursedp=0x0043bab3)  Line 5387 + 0x17 bytes	C++
 	mozjs.dll!LookupPropertyWithFlagsInline(JSContext * cx=0x0607a0e8, JSObject * obj=0x043755b8, int id=76240448, unsigned int flags=65535, JSObject * * objp=0x0043bb0c, JSProperty * * propp=0x0043bb00)  Line 5440 + 0x25 bytes	C++
 	mozjs.dll!js_GetPropertyHelperInline(JSContext * cx=0x0607a0e8, JSObject * obj=0x0663db30, JSObject * receiver=0x0663db30, int id=76240448, unsigned int getHow=1, JS::Value * vp=0x0043c3f0)  Line 5836 + 0x23 bytes	C++
 	mozjs.dll!js_GetPropertyHelper(JSContext * cx=0x0607a0e8, JSObject * obj=0x0663db30, int id=76240448, unsigned int getHow=1, JS::Value * vp=0x0043c3f0)  Line 5929 + 0x1d bytes	C++
 	mozjs.dll!js::Interpret(JSContext * cx=0x0607a0e8, js::StackFrame * entryFrame=0x03d10058, js::InterpMode interpMode=JSINTERP_NORMAL)  Line 3565 + 0x6e bytes	C++
 	mozjs.dll!js::RunScript(JSContext * cx=0x0607a0e8, JSScript * script=0x066c99e8, js::StackFrame * fp=0x03d10058)  Line 614 + 0xf bytes	C++
 	mozjs.dll!js::InvokeKernel(JSContext * cx=0x0607a0e8, const js::CallArgs & argsRef={...}, js::MaybeConstruct construct=NO_CONSTRUCT)  Line 678 + 0x16 bytes	C++
 	mozjs.dll!js::Invoke(JSContext * cx=0x0607a0e8, js::InvokeArgsGuard & args={...}, js::MaybeConstruct construct=NO_CONSTRUCT)  Line 167 + 0x11 bytes	C++
 	mozjs.dll!js::Invoke(JSContext * cx=0x0607a0e8, const JS::Value & thisv={...}, const JS::Value & fval={...}, unsigned int argc=0, JS::Value * argv=0x00000000, JS::Value * rval=0x0043ca30)  Line 710 + 0xf bytes	C++
 	mozjs.dll!JS_CallFunctionValue(JSContext * cx=0x0607a0e8, JSObject * obj=0x0663db30, JS::Value fval={...}, unsigned int argc=0, JS::Value * argv=0x00000000, JS::Value * rval=0x0043ca30)  Line 5030 + 0x2a bytes	C++
 	xul.dll!nsXBLProtoImplAnonymousMethod::Execute(nsIContent * aBoundElement=0x0818e008)  Line 337 + 0x2d bytes	C++
 	xul.dll!nsXBLPrototypeBinding::BindingAttached(nsIContent * aBoundElement=0x0818e008)  Line 482 + 0x12 bytes	C++
 	xul.dll!nsXBLBinding::ExecuteAttachedHandler()  Line 963	C++
 	xul.dll!nsBindingManager::ProcessAttachedQueue(unsigned int aSkipSize=0)  Line 1037	C++
 	xul.dll!PresShell::InitialReflow(int aWidth=39600, int aHeight=30180)  Line 1946	C++
 	xul.dll!mozilla::dom::MediaDocument::StartLayout()  Line 314 + 0x20 bytes	C++
 	xul.dll!mozilla::dom::MediaDocumentStreamListener::OnStartRequest(nsIRequest * request=0x0aed3088, nsISupports * ctxt=0x00000000)  Line 87	C++
 	xul.dll!nsDocumentOpenInfo::OnStartRequest(nsIRequest * request=0x0aed3088, nsISupports * aCtxt=0x00000000)  Line 304 + 0x24 bytes	C++
 	xul.dll!nsHttpChannel::CallOnStartRequest()  Line 725 + 0x44 bytes	C++
 	xul.dll!nsHttpChannel::ContinueProcessNormal(unsigned int rv=0)  Line 1211 + 0x8 bytes	C++
 	xul.dll!nsHttpChannel::ProcessNormal()  Line 1149	C++
 	xul.dll!nsHttpChannel::ProcessResponse()  Line 1002 + 0x8 bytes	C++
 	xul.dll!nsHttpChannel::OnStartRequest(nsIRequest * request=0x02f5aad0, nsISupports * ctxt=0x00000000)  Line 4063 + 0xe bytes	C++
 	xul.dll!nsInputStreamPump::OnStateStart()  Line 441 + 0x2c bytes	C++
 	xul.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x063a4ef8)  Line 397 + 0xb bytes	C++
 	xul.dll!nsOutputStreamReadyEvent::Run()  Line 115	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0043ce30)  Line 631 + 0x19 bytes	C++
 	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x02a30b18, int mayWait=1)  Line 245 + 0x16 bytes	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x00a3eb18)  Line 134 + 0xe bytes	C++
 	xul.dll!MessageLoop::RunInternal()  Line 209	C++
 	xul.dll!MessageLoop::RunHandler()  Line 202	C++
 	xul.dll!MessageLoop::Run()  Line 176	C++
 	xul.dll!nsBaseAppShell::Run()  Line 191	C++
 	xul.dll!nsAppShell::Run()  Line 261 + 0x9 bytes	C++
 	xul.dll!nsAppStartup::Run()  Line 228 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00a31fc0, const nsXREAppData * aAppData=0x00a346f8)  Line 3557 + 0x25 bytes	C++
 	firefox.exe!do_main(const char * exePath=0x0043f76c, int argc=1, char * * argv=0x00a31fc0)  Line 198 + 0x12 bytes	C++
 	firefox.exe!NS_internal_main(int argc=1, char * * argv=0x00a31fc0)  Line 281 + 0x14 bytes	C++
 	firefox.exe!wmain(int argc=1, wchar_t * * argv=0x00a33f20)  Line 107 + 0xd bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 583 + 0x17 bytes	C
 	kernel32.dll!759d3677() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	ntdll.dll!77239d72() 	
 	ntdll.dll!77239d45()
Comment 40 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 09:31:58 PDT
What does the JS stack look like at that CallResolveOp call?  Note that you'll need to step out of the nested JS invocation that InstallField does to get that info.
Comment 41 Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 09:33:52 PDT
Followup is fine as long as it's actually dealt with.
Comment 42 Asa Dotzler [:asa] 2011-10-04 14:55:51 PDT
Jared, were there any changes here that could impact extensions who might have jumped on your new code before this backout?
Comment 43 Jared Wein [:jaws] (please needinfo? me) 2011-10-04 15:00:44 PDT
(In reply to Asa Dotzler [:asa] from comment #42)
> Jared, were there any changes here that could impact extensions who might
> have jumped on your new code before this backout?

I'm not sure if any addons were written to depend on the now-backed-out behavior.

From what I understand, the feature was introduced by the patch that got backed out, and so the new feature has only been active in Aurora since the Fx9->Aurora merge.
Comment 44 Alexandre Poirot [:ochameau] 2011-10-04 15:27:43 PDT
(In reply to Asa Dotzler [:asa] from comment #42)
> Jared, were there any changes here that could impact extensions who might
> have jumped on your new code before this backout?

The new code has been requested for jetpack, in order to improve our page-mod API against medias. This API wasn't working on media documents. So I think we can say that no addons is really concerned by this backout. We are just delaying a bugfix for jetpack APIs.
Comment 45 Jared Wein [:jaws] (please needinfo? me) 2011-10-04 15:29:42 PDT
http://hg.mozilla.org/releases/mozilla-aurora/rev/aae5e17fb70c
Comment 46 Asa Dotzler [:asa] 2011-10-04 16:12:24 PDT
Thanks ochameau and jwein.
Comment 47 Gabor Krizsanits [:krizsa :gabor] 2011-10-05 06:04:34 PDT
(In reply to Boris Zbarsky (:bz) from comment #40)
> What does the JS stack look like at that CallResolveOp call?  Note that
> you'll need to step out of the nested JS invocation that InstallField does
> to get that info.

1 level deep with an anonym function from videocontrols.xml:5
the |this| is a XULElement (it's parent is a HTMLVideoElement)

The line number (5) does not make much sense to me, I don't know how to interpret that number in case of an xml file like that. I _guess_ it's an xbl constructed function from a constructor.
Comment 48 Boris Zbarsky [:bz] (still a bit busy) 2011-10-05 08:22:52 PDT
Generally, the line numbers for XBL should make sense.  Don't know why it doesn't here.

But yes, the stack above shows that we're coming from a constructor from StartLayout.  That's the normal thing that should happen.

Let's spin off this part into a separate bug, I guess?  Then look at that nsXBLProtoImplAnonymousMethod::Execute and see what sort of nsIScriptContext it's finding?
Comment 49 Gabor Krizsanits [:krizsa :gabor] 2011-10-05 09:29:00 PDT
Follow up: bug 692132
Comment 50 Simona B [:simonab ] 2011-11-22 03:02:16 PST
On a heavily profile the issue is no longer reproducible on Firefox 9.0b2 and on Aurora. 
Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111121 Firefox/10.0a2

But, I can still reproduce this on the latest Nightly. Video controls are not shown when viewing the OGG file from the Description.
Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111121 Firefox/11.0a1

Should this bug be reopened?
Comment 51 Boris Zbarsky [:bz] (still a bit busy) 2011-11-22 05:20:01 PST
> But, I can still reproduce this on the latest Nightly.

That's bug 701662.  I'm surprised you didn't hit it on Aurora.  I believe this bug should be left as-is.
Comment 52 Simona B [:simonab ] 2011-11-22 06:02:27 PST
Considering Comment 51 marking this as [qa?].
Comment 53 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-11-22 08:32:08 PST
(In reply to Boris Zbarsky (:bz) from comment #51)
> > But, I can still reproduce this on the latest Nightly.
> 
> That's bug 701662.  

How is this bug different from that bug?
Comment 54 Boris Zbarsky [:bz] (still a bit busy) 2011-11-22 09:28:25 PST
This bug always showed up, and was caused by a certain code change.  It's fixed in Firefox 9, where it could originally be reproduced.

That bug only shows up on the second and later startups (when the XBL is being fastloaded), was caused by a different code change, and didn't start showing up until Firefox 10.

So they're about as different as two different crash bugs, say.  Similar (but not identical) symptoms, totally different causes.
Comment 55 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-11-22 11:45:55 PST
Thanks for that clarification Boris. In testing, how do we prove that the symptom (no video controls) is not being caused by this bug in particular.
Comment 56 Jared Wein [:jaws] (please needinfo? me) 2011-11-22 14:06:25 PST
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #55)
> Thanks for that clarification Boris. In testing, how do we prove that the
> symptom (no video controls) is not being caused by this bug in particular.

The easiest way to reproduce this bug was to install a JetPack add-on that uses the PageMod API. The bug would only appear if the addon was enabled.
Comment 57 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-11-22 14:17:10 PST
Thanks Jared.
Comment 58 Boris Zbarsky [:bz] (still a bit busy) 2011-11-22 14:43:59 PST
> how do we prove that the symptom (no video controls) is not being caused by this bug in
> particular.

If the symptom appears on the first startup with a clean profile, it could be caused by this bug.

If it does not, then this bug is not an issue.
Comment 59 Gabriela [:gaby2300] 2011-12-02 13:14:33 PST
Verified fixed in Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 using Windows 7
Comment 60 Simona B [:simonab ] 2011-12-07 06:06:09 PST
Verified that this issue is fixed on Firefox 9 beta 4 and the latest Aurora. Tested on Windows XP, Windows 7, Ubuntu 10.10 and Mac OS X 10.6. After installing NoScript add-on on a clean profile, at the first startup the video controls are shown. 

Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111206 Firefox/10.0a2

Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0
Mozilla/5.0 (Windows NT 6.1; rv:10.0a2) Gecko/20111206 Firefox/10.0a2

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2

NOTE: I can still reproduce this on the latest Nightly, as far as I can see in the comments of this bug, this appear to not have been landed on Nightly.
The steps I used to reproduce this issue are:
1. Start Firefox with a clean profile.
2. Install NoScript add-on and restart.
3. Load video 
http://videos-cdn.mozilla.net/serv/air_mozilla/07272011_brownbag.ogg

No video controls are shown after step 3.
Comment 61 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-13 13:40:31 PST
Boris, should this be reopened based on Simona's comment 60, or is that a new bug?
Comment 62 Boris Zbarsky [:bz] (still a bit busy) 2011-12-13 16:18:19 PST
Separate bug, please.  Needs debugging, a regression range, etc.  Putting that info in the new bug would be much appreciated.
Comment 63 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-13 16:44:28 PST
Marking this VERIFIED based on comment 62 and previous testing. Simona, please open a new bug given the info requested in comment 62. Thanks
Comment 64 Simona B [:simonab ] 2011-12-20 04:51:57 PST
As per comment 62 and 63 opened Bug 712264.

Note You need to log in before you can comment on or make changes to this bug.