No video controls when directly viewing a video

VERIFIED FIXED in Firefox 9

Status

()

Toolkit
Video/Audio Controls
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: Dolske, Assigned: jaws)

Tracking

({regression, verified-aurora, verified-beta})

9 Branch
mozilla9
regression, verified-aurora, verified-beta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox9 fixed)

Details

(Whiteboard: [fixed-in-fx-team][qa+][qa!:9][qa!:10])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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.
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]
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4495e1f795c2&tochange=c71229984353

Bug 660233 looks like a suspect here.
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?
I'm having trouble reproducing this bug now with a new build from mozilla-central.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Keywords: regressionwindow-wanted
> 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...
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(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?
Well, I was sort of guessing based on what looked like scary xpconnect changes.  Somebody could actually bisect here ;-)
Keywords: regression, regressionwindow-wanted
Indeed.  Whoever can reproduce the bug and build should just bisect....
The merge across to aurora (for Firefox 9) contains this bug, we must land out fix on Aurora as well as central.
Target Milestone: --- → mozilla9
Version: unspecified → 9 Branch
status-firefox9: --- → affected
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.
I forgot to mention above that my attempt to hg bisect was using a relatively clean profile.
Duplicate of this bug: 689915
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
Blocks: 678465
Keywords: regressionwindow-wanted
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.
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
Attachment #563255 - Flags: review?(jonas)
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?
Alex, do you have any ideas about comment 17?
Comment on attachment 563255 [details] [diff] [review]
Backout of revision 379147b5215f

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

r=me
Attachment #563255 - Flags: review?(jonas) → review+
Blocks: 690208

Comment 20

6 years ago
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
With bugzilla tweaks 1.11 turned on the bug can be reproduced, when it's disabled the bug is gone.
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);
(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.
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...
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).
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?
(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.
OK, and the video itself is there, just not the controls?
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.
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...
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?
It's all possible, but pretty unlikely....
(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.
So (mixing JS and C++ a bit here), JS_GetParent(this.Utils) is the ChromeWindow?  What compartment is this.Utils allocated in?
I noticed today that the video controls appear to work when viewing the video in full screen mode.
Attachment #563255 - Flags: approval-mozilla-aurora?
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.
Whiteboard: [fixed-in-fx-team]
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.
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?
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
(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()
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.
Followup is fine as long as it's actually dealt with.

Updated

6 years ago
Attachment #563255 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 42

6 years ago
Jared, were there any changes here that could impact extensions who might have jumped on your new code before this backout?
(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.
(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.
http://hg.mozilla.org/releases/mozilla-aurora/rev/aae5e17fb70c

Comment 46

6 years ago
Thanks ochameau and jwein.
(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.
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?
Follow up: bug 692132
status-firefox9: affected → fixed
Whiteboard: [fixed-in-fx-team] → [fixed-in-fx-team][qa+]
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?
> 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.
Considering Comment 51 marking this as [qa?].
Whiteboard: [fixed-in-fx-team][qa+] → [fixed-in-fx-team][qa?]
(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?
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.
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.
(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.
Thanks Jared.
Whiteboard: [fixed-in-fx-team][qa?] → [fixed-in-fx-team][qa+]
> 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.
Verified fixed in Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 using Windows 7
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.
Keywords: verified-aurora, verified-beta
Boris, should this be reopened based on Simona's comment 60, or is that a new bug?
Whiteboard: [fixed-in-fx-team][qa+] → [fixed-in-fx-team][qa+][qa!:9][qa!:10]
Separate bug, please.  Needs debugging, a regression range, etc.  Putting that info in the new bug would be much appreciated.
Marking this VERIFIED based on comment 62 and previous testing. Simona, please open a new bug given the info requested in comment 62. Thanks
Status: RESOLVED → VERIFIED
As per comment 62 and 63 opened Bug 712264.
You need to log in before you can comment on or make changes to this bug.