878673 - 3D siverlight Videos on 3dvisionlive.com with Firefox Version 22 beta does not play in stereo

Reporter

Description

•

11 years ago

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; chromeframe/28.0.1500.29; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)

Steps to reproduce:

1) Install NVIDIA sytem with stereo 3d. Install NVIDIA drivers and enable stereo 3d from NVIDIA control panel. 
2) Install latest Firefox browser Version 22 
3) Install latest version of silverlight plugin 
4) Go to www.3dvisionlive.com and click on the 3D Videos tab. 


Actual results:

Videos playing as split images. No stereo effect is observed.


Expected results:

Video should have played in stereo 3d.

Regression:
Works fine with Firefox Version 21
Issue repro with Aurora 23.0a2.

testing.s3d

Reporter

Comment 1

•

11 years ago

Initial Observation:
Initial first look is pointing to the NVIDIA browser plugin not being loaded by FF. This plugin is required for stereo operation.

It is included in each Silverlight video page as:
For example in source code of page of http://www.3dvisionlive.com/ugc/24971/lumion-urban-girl 
...
      <div id="vms_embed_code" class="ie-version0"><embed id="imageE" type="application/mozilla-3DV-streaming-plugin" hidden="true" width="0" height="0" style="position:absolute;top:- 20px;left:-20px;"></embed>
...

npnv3dvstreaming.dll is present in <>/Program Files(x86)/NVIDIA Corporation/3d vision/ is the plugin dll.
In system registry you would find entries at HKLM/software/../mozillaplugins/@nvidia.com/3dvisionstreaming/mimetypes/application/mozilla-3dv-streaming-plugin

testing.s3d

Reporter

Comment 2

•

11 years ago

Additional regression info:

As per mozregression:

Last good nightly:2013-03-05
First bad nightly:2013-03-06

dates are in (yyyy-mm-dd) format

This issue introduced from nightly:2013-03-06 onwards.

Alex Keybl [:akeybl]

Comment 3

•

11 years ago

Milan, can anybody take a look at this regression range? If there's a simple backout/change that we can make in the FF22 timeframe, we may still be able to prevent a release regression. Otherwise, this may have to be mitigated in a later release.

status-firefox21: --- → unaffected

status-firefox22: --- → affected

status-firefox23: --- → affected

status-firefox24: --- → affected

tracking-firefox22: --- → ?

tracking-firefox23: --- → +

tracking-firefox24: --- → +

Flags: needinfo?(milan)

Keywords: regression

Milan Sreckovic [:milan] (needinfo for best results)

Comment 4

•

11 years ago

Benoit, lets see if we can setup Guillaume to bisect this for us and see which actual change caused the problem?

Flags: needinfo?(milan) → needinfo?(bjacob)

Milan Sreckovic [:milan] (needinfo for best results)

Comment 5

•

11 years ago

Guillaume is tracking this down as we speak.

Flags: needinfo?(bjacob)

Alex Keybl [:akeybl]

Comment 6

•

11 years ago

Any updates? Today's the last day to take a fix in the FF22 timeframe. Otherwise, a fix will be pushed off till FF23.

Flags: needinfo?(milan)

Flags: needinfo?(gabadie)

Guillaume Abadie

Comment 7

•

11 years ago

Sorry I'm doing everything I can. The bisection is pretty much longer than expected because of build errors with a lot of repos.

Flags: needinfo?(gabadie)

Milan Sreckovic [:milan] (needinfo for best results)

Comment 8

•

11 years ago

What Guillaume said. We had some false starts.

Flags: needinfo?(milan)

Guillaume Abadie

Comment 9

•

11 years ago

Attached image screenshot of nightly 2013-03-06 — Details

Showing the nightly 2013-03-06 working on the specified webpage.

Guillaume Abadie

Comment 10

•

11 years ago

I do apologies for double post.

I've done a new bisection today, and all tests were good now. Therefor I've tried again the 2013-03-06 nightly, and it works has we can see on the screenshot. Does something have been changed on this video ?

testing.s3d

Reporter

Comment 11

•

11 years ago

Attached image 2013-03-06_notworking — Details

testing.s3d

Reporter

Comment 12

•

11 years ago

Attached image 2013-03-05_working — Details

testing.s3d

Reporter

Comment 13

•

11 years ago

Reconfirmed the regression info again today with the same video.

Refer attached snapshots :
2013-03-06_notworking.png
2013-03-05_working.png

Milan Sreckovic [:milan] (needinfo for best results)

Comment 14

•

11 years ago

So did we.  It may point to some timing or initialization issue, as it appears to have first succeeded, then subsequently keeps failing on the same build.  Will continue the search.

Alex Keybl [:akeybl]

Updated

•

11 years ago

status-firefox21: unaffected → wontfix

status-firefox22: affected → wontfix

tracking-firefox22: ? → +

testing.s3d

Reporter

Comment 15

•

11 years ago

Couple of suspicious code blocks are hit indicating mURI is NULL and later indicating 'Not instantiating plugin with no frame' for "application/mozilla-3DV-streaming-plugin"

Some extracts from code flow taken:

(1)

File:
\\firefox-22.0b4.source\mozilla-beta\content\base\src\nsObjectLoadingContent.cpp

Var:
-		this	0x09280b68 {mIsDoneAddingChildren=true }	nsObjectLoadingContent * const
-		mContentType	{...}	nsCString
+		nsACString_internal	{mData=0x04b065f0 "application/mozilla-3DV-streaming-plugin" mLength=40 mFlags=5 }	nsACString_internal

+		mURI	{mRawPtr=0x00000000 }	nsCOMPtr<nsIURI>
+		mOriginalURI	{mRawPtr=0x00000000 }	nsCOMPtr<nsIURI>
+		mBaseURI	{mRawPtr=0x0f828a28 }	nsCOMPtr<nsIURI>


code:
...
    case eType_Plugin:

      objectType = nsIContentPolicy::TYPE_OBJECT;

      break;
..

Stack:
>	xul.dll!nsObjectLoadingContent::CheckProcessPolicy(aContentPolicy=0x0030f400)  Line 1212	C++
 	xul.dll!nsObjectLoadingContent::LoadObject(aNotify=true, aForceLoad=false, aLoadingChannel=0x00000000)  Line 1785	C++
 	xul.dll!nsObjectLoadingContent::LoadObject(aNotify=true, aForceLoad=false)  Line 1646	C++
 	xul.dll!mozilla::dom::HTMLSharedObjectElement::StartObjectLoad(aNotify=true)  Line 328	C++
 	xul.dll!mozilla::dom::HTMLSharedObjectElement::StartObjectLoad()  Line 92	C++
 	xul.dll!nsRunnableMethodImpl<void (__thiscall mozilla::dom::HTMLSharedObjectElement::*)(void),1>::Run()  Line 351	C++
 	xul.dll!nsContentUtils::RemoveScriptBlocker()  Line 5056	C++
 	xul.dll!nsDocument::EndUpdate(aUpdateType=1)  Line 4230	C++
 	xul.dll!nsHTMLDocument::EndUpdate(aUpdateType=1)  Line 2578	C++
 	xul.dll!nsHtml5TreeOpExecutor::EndDocUpdate()  Line 249	C++
 	xul.dll!nsHtml5TreeOpExecutor::RunFlushLoop()  Line 584	C++
 	xul.dll!nsHtml5ExecutorFlusher::Run()  Line 127	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=false, result=0x0030f5e3)  Line 627	C++
 	xul.dll!NS_ProcessNextEvent(thread=0x0081d888, mayWait=false)  Line 238	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(aDelegate=0x008179a8)  Line 82	C++
 	xul.dll!MessageLoop::RunInternal()  Line 217	C++
 	xul.dll!MessageLoop::RunHandler()  Line 210	C++
 	xul.dll!MessageLoop::Run()  Line 184	C++
 	xul.dll!nsBaseAppShell::Run()  Line 165	C++
 	xul.dll!nsAppShell::Run()  Line 161	C++
 	xul.dll!nsAppStartup::Run()  Line 288	C++
 	xul.dll!XREMain::XRE_mainRun()  Line 3868	C++
 	xul.dll!XREMain::XRE_main(argc=1, argv=0x00ca1760, aAppData=0x0030fafc)  Line 3935	C++
 	xul.dll!XRE_main(argc=1, argv=0x00ca1760, aAppData=0x0030fafc, aFlags=0)  Line 4140	C++
 	firefox.exe!do_main(argc=1, argv=0x00ca1760, xreDirectory=0x00ca5c50)  Line 273	C++
 	firefox.exe!NS_internal_main(argc=1, argv=0x00ca1760)  Line 583	C++
 	firefox.exe!wmain(argc=1, argv=0x00ca1258)  Line 105	C++
 	firefox.exe!__tmainCRTStartup()  Line 552	C
 	firefox.exe!wmainCRTStartup()  Line 371	C

(2)

File:
\\firefox-22.0b4.source\mozilla-beta\caps\src\nsScriptSecurityManager.cpp

Var:
+		aURI	0x00000000	nsIURI *

Code:
..
  NS_ENSURE_ARG(aURI);
..

Stack:
>	xul.dll!nsScriptSecurityManager::GetCodebasePrincipalInternal(aURI=0x00000000, aAppId=0, aInMozBrowser=false, result=0x0030eed0)  Line 1936	C++
 	xul.dll!nsScriptSecurityManager::GetNoAppCodebasePrincipal(aURI=0x00000000, aPrincipal=0x0030eed0)  Line 1898	C++
 	xul.dll!`anonymous namespace'::GetPrincipal(aURI=0x00000000, aPrincipal=0x0030eed0)  Line 109	C++
 	xul.dll!nsPermissionManager::TestPermission(aURI=0x00000000, aType=0x660070d0, aPermission=0x0030f014)  Line 976	C++
 	xul.dll!nsContentBlocker::TestPermission(aCurrentURI=0x00000000, aFirstURI=0x0387c058, aContentType=5, aPermission=0x0030f05f, aFromPrefs=0x0030f057)  Line 249	C++
 	xul.dll!nsContentBlocker::ShouldProcess(aContentType=5, aContentLocation=0x00000000, aRequestingLocation=0x0387c058, aRequestingContext=0x09280b68, aMimeGuess={...}, aExtra=0x00000000, aRequestPrincipal=0x0c061af8, aDecision=0x0030f400)  Line 211	C++
 	xul.dll!nsContentPolicy::CheckPolicy(policyMethod=0x631adfe0, contentType=5, contentLocation=0x00000000, requestingLocation=0x0387c058, requestingContext=0x09280b68, mimeType={...}, extra=0x00000000, requestPrincipal=0x0c061af8, decision=0x0030f400)  Line 127	C++
 	xul.dll!nsContentPolicy::ShouldProcess(contentType=5, contentLocation=0x00000000, requestingLocation=0x0387c058, requestingContext=0x09280b68, mimeType={...}, extra=0x00000000, requestPrincipal=0x0c061af8, decision=0x0030f400)  Line 209	C++
 	xul.dll!NS_CheckContentProcessPolicy(contentType=5, contentLocation=0x00000000, originPrincipal=0x0c061af8, context=0x09280b68, mimeType={...}, extra=0x00000000, decision=0x0030f400, policyService=0x054a3d90, aSecMan=0x037e61a0)  Line 239	C++
 	xul.dll!nsObjectLoadingContent::CheckProcessPolicy(aContentPolicy=0x0030f400)  Line 1229	C++
 	xul.dll!nsObjectLoadingContent::LoadObject(aNotify=true, aForceLoad=false, aLoadingChannel=0x00000000)  Line 1785	C++
 	xul.dll!nsObjectLoadingContent::LoadObject(aNotify=true, aForceLoad=false)  Line 1646	C++
 	xul.dll!mozilla::dom::HTMLSharedObjectElement::StartObjectLoad(aNotify=true)  Line 328	C++
 	xul.dll!mozilla::dom::HTMLSharedObjectElement::StartObjectLoad()  Line 92	C++
 	xul.dll!nsRunnableMethodImpl<void (__thiscall mozilla::dom::HTMLSharedObjectElement::*)(void),1>::Run()  Line 351	C++
 	xul.dll!nsContentUtils::RemoveScriptBlocker()  Line 5056	C++
 	xul.dll!nsDocument::EndUpdate(aUpdateType=1)  Line 4230	C++
 	xul.dll!nsHTMLDocument::EndUpdate(aUpdateType=1)  Line 2578	C++
 	xul.dll!nsHtml5TreeOpExecutor::EndDocUpdate()  Line 249	C++
 	xul.dll!nsHtml5TreeOpExecutor::RunFlushLoop()  Line 584	C++
 	xul.dll!nsHtml5ExecutorFlusher::Run()  Line 127	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=false, result=0x0030f5e3)  Line 627	C++
 	xul.dll!NS_ProcessNextEvent(thread=0x0081d888, mayWait=false)  Line 238	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(aDelegate=0x008179a8)  Line 82	C++
 	xul.dll!MessageLoop::RunInternal()  Line 217	C++
 	xul.dll!MessageLoop::RunHandler()  Line 210	C++
 	xul.dll!MessageLoop::Run()  Line 184	C++
 	xul.dll!nsBaseAppShell::Run()  Line 165	C++
 	xul.dll!nsAppShell::Run()  Line 161	C++
 	xul.dll!nsAppStartup::Run()  Line 288	C++
 	xul.dll!XREMain::XRE_mainRun()  Line 3868	C++
 	xul.dll!XREMain::XRE_main(argc=1, argv=0x00ca1760, aAppData=0x0030fafc)  Line 3935	C++
 	xul.dll!XRE_main(argc=1, argv=0x00ca1760, aAppData=0x0030fafc, aFlags=0)  Line 4140	C++
 	firefox.exe!do_main(argc=1, argv=0x00ca1760, xreDirectory=0x00ca5c50)  Line 273	C++
 	firefox.exe!NS_internal_main(argc=1, argv=0x00ca1760)  Line 583	C++
 	firefox.exe!wmain(argc=1, argv=0x00ca1258)  Line 105	C++
 	firefox.exe!__tmainCRTStartup()  Line 552	C


(3)
File:
\\firefox-22.0b4.source\mozilla-beta\content\base\src\nsObjectLoadingContent.cpp

Var:
-		this	0x09280b68 {mIsDoneAddingChildren=true }	nsObjectLoadingContent * const
-		mContentType	{...}	nsCString
+		nsACString_internal	{mData=0x04b065f0 "application/mozilla-3DV-streaming-plugin" mLength=40 mFlags=5 }	nsACString_internal

-		thisContent	{mRawPtr=0x09280b20 }	nsCOMPtr<nsIContent>
-		mRawPtr	0x09280b20 {mIsDoneAddingChildren=true }	nsIContent *
-		nsINode	{mNodeInfo={...} mParent=0x091fc310 mFlags=2097152 ...}	nsINode
+		mPrimaryFrame	0x00000000 {mRect={...} mContent=??? mStyleContext=??? ...}	nsIFrame *


Code:
..
  if (!thisContent->GetPrimaryFrame()) {

    LOG(("OBJLC [%p]: Not instantiating plugin with no frame", this));

    return NS_OK;

  }
..

Stack:

>	xul.dll!nsObjectLoadingContent::InstantiatePluginInstance(aIsLoading=false)  Line 752	C++
 	xul.dll!nsObjectLoadingContent::SyncStartPluginInstance()  Line 2421	C++
 	xul.dll!nsAsyncInstantiateEvent::Run()  Line 139	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=true, result=0x0030ef03)  Line 627	C++
 	xul.dll!NS_ProcessNextEvent(thread=0x0081d888, mayWait=true)  Line 238	C++
 	xul.dll!nsThread::Shutdown()  Line 474	C++
 	xul.dll!nsDestroyThreadEvent::Run()  Line 39	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=true, result=0x0030eff7)  Line 627	C++
 	xul.dll!NS_ProcessNextEvent(thread=0x0081d888, mayWait=true)  Line 238	C++
 	xul.dll!nsThread::Shutdown()  Line 474	C++
 	xul.dll!mozilla::LazyIdleThread::ShutdownThread()  Line 273	C++
 	xul.dll!mozilla::LazyIdleThread::Notify(aTimer=0x05118718)  Line 461	C++
 	xul.dll!nsTimerImpl::Fire()  Line 543	C++
 	xul.dll!nsTimerEvent::Run()  Line 625	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=true, result=0x0030f313)  Line 627	C++
 	xul.dll!NS_ProcessNextEvent(thread=0x0081d888, mayWait=true)  Line 238	C++
 	xul.dll!nsThread::Shutdown()  Line 474	C++
 	xul.dll!nsRunnableMethodImpl<enum tag_nsresult (__stdcall nsIThread::*)(void),1>::Run()  Line 351	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=true, result=0x0030f403)  Line 627	C++
 	xul.dll!NS_ProcessNextEvent(thread=0x0081d888, mayWait=true)  Line 238	C++
 	xul.dll!nsThread::Shutdown()  Line 474	C++
 	xul.dll!nsRunnableMethodImpl<enum tag_nsresult (__stdcall nsIThread::*)(void),1>::Run()  Line 351	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=true, result=0x0030f4f3)  Line 627	C++
 	xul.dll!NS_ProcessNextEvent(thread=0x0081d888, mayWait=true)  Line 238	C++
 	xul.dll!nsThread::Shutdown()  Line 474	C++
 	xul.dll!nsRunnableMethodImpl<enum tag_nsresult (__stdcall nsIThread::*)(void),1>::Run()  Line 351	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=false, result=0x0030f5e3)  Line 627	C++
 	xul.dll!NS_ProcessNextEvent(thread=0x0081d888, mayWait=false)  Line 238	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(aDelegate=0x008179a8)  Line 82	C++
 	xul.dll!MessageLoop::RunInternal()  Line 217	C++
 	xul.dll!MessageLoop::RunHandler()  Line 210	C++
 	xul.dll!MessageLoop::Run()  Line 184	C++
 	xul.dll!nsBaseAppShell::Run()  Line 165	C++
 	xul.dll!nsAppShell::Run()  Line 161	C++
 	xul.dll!nsAppStartup::Run()  Line 288	C++
 	xul.dll!XREMain::XRE_mainRun()  Line 3868	C++
 	xul.dll!XREMain::XRE_main(argc=1, argv=0x00ca1760, aAppData=0x0030fafc)  Line 3935	C++
 	xul.dll!XRE_main(argc=1, argv=0x00ca1760, aAppData=0x0030fafc, aFlags=0)  Line 4140	C++
 	firefox.exe!do_main(argc=1, argv=0x00ca1760, xreDirectory=0x00ca5c50)  Line 273	C++
 	firefox.exe!NS_internal_main(argc=1, argv=0x00ca1760)  Line 583	C++
 	firefox.exe!wmain(argc=1, argv=0x00ca1258)  Line 105	C++
 	firefox.exe!__tmainCRTStartup()  Line 552	C
 	firefox.exe!wmainCRTStartup()  Line 371	C

Guillaume Abadie

Comment 16

•

11 years ago

bisection finaly complete ! (sorry for long processing time, had a merge between mozilla-central and mozilla-inbound)

The first bad revision is 123797:f73c5ece0869 fixing bug 614825

Status: UNCONFIRMED → NEW

Ever confirmed: true

Guillaume Abadie

Updated

•

11 years ago

Blocks: 614825

Flags: needinfo?(mounir)

Milan Sreckovic [:milan] (needinfo for best results)

Comment 17

•

11 years ago

Boris, you reviewed bug 614825, just wondering if you'd have insight into this as well.

Flags: needinfo?(bzbarsky)

Boris Zbarsky [:bzbarsky]

Comment 18

•

11 years ago

I don't know what there is to say.  In general, sites depend on us not instantiating display:none plug-ins, so we don't.  Per spec, @hidden means display:none, so this plug-in is not getting instantiated.

Does this work in any other browser?  If so, why?

Flags: needinfo?(bzbarsky)

Benoit Jacob [:bjacob] (mostly away)

Comment 19

•

11 years ago

Hm, I think that we're the only browser supporting this 3D stuff, and comment 18 sounds like even in Firefox, this only ever worked by accident...!

Flags: needinfo?(mounir)

Milan Sreckovic [:milan] (needinfo for best results)

Comment 20

•

11 years ago

Sounds like our bug cancelled a plug-in bug, and once we fixed out bug, the plug-in bug got exposed? That seems like a reasonable explanation.

Boris Zbarsky [:bzbarsky]

Comment 21

•

11 years ago

A page bug, actually, not a plug-in bug.

Milan Sreckovic [:milan] (needinfo for best results)

Comment 22

•

11 years ago

Got it - that would certainly explain while (for at least a day) it seemed to work with the version that before and after that day, failed.

testing.s3d

Reporter

Comment 23

•

11 years ago

Hi,

So what would be the recommendation from the spec if we want to load the plugin and use it but not to show it/keep it hidden?

Thanks!

Benoit Jacob [:bjacob] (mostly away)

Comment 24

•

11 years ago

Boris, please help answer the question in comment 23 ?

Flags: needinfo?(bzbarsky)

Boris Zbarsky [:bzbarsky]

Comment 25

•

11 years ago

Probably setting its width and height to 0 should be sufficient, no?

Flags: needinfo?(bzbarsky)

testing.s3d

Reporter

Comment 26

•

11 years ago

Thanks!

Made website side changes to remove the hidden attribute and kept width and height as 0.

The 3d videos are working fine now with FF22 beta.

Alex Keybl [:akeybl]

Updated

•

11 years ago

Status: NEW → RESOLVED

Closed: 11 years ago

status-firefox22: wontfix → unaffected

status-firefox23: affected → unaffected

status-firefox24: affected → unaffected

tracking-firefox22: + → -

tracking-firefox23: + → -

tracking-firefox24: + → -

Resolution: --- → WORKSFORME

Christoph Hipp

Comment 27

•

11 years ago

Hello, 

in prior versions of FF a plugin was loaded when the hidden attribute was specified.

Many users/customers of our plugin use the hidden attribute like this: hidden="false" or hidden="true". Since FF 22 this leads to the effect that the plugin is not loaded at all, no matter what the attribute value is set to. It only depends on the existence of the hidden attribute.

A WORKSFORME resolution is, in my mind, not enough to close this issue that introduces a breaking change to all versions of FF before.

Is it possible, to revert the logic of the hidden attribute to the logic before FF Version 22 (like other browsers behave)?

Thanks!

Milan Sreckovic [:milan] (needinfo for best results)

Comment 28

•

11 years ago

(In reply to Christoph Hipp from comment #27)
> Hello, 
> 
> in prior versions of FF a plugin was loaded when the hidden attribute was
> specified.
>...

True, but according to comment 18 and bug 614825, the previous behaviour was due to a bug in Firefox.

Christoph Hipp

Comment 29

•

11 years ago

(In reply to Milan Sreckovic [:milan] from comment #28)
> (In reply to Christoph Hipp from comment #27)
> > in prior versions of FF a plugin was loaded when the hidden attribute was
> > specified.
> >...
> 
> True, but according to comment 18 and bug 614825, the previous behaviour was
> due to a bug in Firefox.

Our plugin exists even longer than Firefox and was running in Netscape Navigator using the hidden attribute like described in comment #27. So, this "bug" that this item claimed to have fixed, is almost as old as the www. For us, this breaking change with FF 22 is coming somewhat out of the blue and unexpected. Other browsers like Chrome or Safari still load plugins with a hidden attribute - just like FF 21 did.

Please imagine this: 
A company sells a web application that uses a NPAPI plugin somewhere in the application. Let's assume that the code instantiating the plugin via the embed tag uses hidden="false".

The effect after the updating to FF 22 is: 
The users can't work with the web application anymore, since the plugin is not started on Firefox browsers anymore. 
The only "fix" in this case is, to update all of the installed web applications to no longer use the hidden attribute in the embed tag.

That's why we think that it would beed good, for potentially many plugins and web applications, to revert to the logic of FF 21.

Boris Zbarsky [:bzbarsky]

Comment 30

•

11 years ago

Is your plugin loaded in other browsers if the embed or object is explicitly styled with display:none by the page?  What about in Firefox 21?

Christoph Hipp

Comment 31

•

11 years ago

(In reply to Boris Zbarsky (:bz) (reading mail, but on paternity leave) from comment #30)
> Is your plugin loaded in other browsers if the embed or object is explicitly
> styled with display:none by the page?  What about in Firefox 21?

I can't test this right now (maybe tomorrow), but this not really applicable for us, since we do not set a style at all. 

Our problem is that the plugin is instantiated by our web application using hidden="false" attribute of the embed tag. This is a fact in hundreds of installations. 
The change introduced with FF 22 renders the application now completely useless for all Firefox 22 users. 

This is very unfortunate for end users, our customers and us as vendor. To make the web application run again with Firefox, all installations would have to be updated/patched. You probably can imagine that this means a lot of work.

We currently do not fully understand, why the change was necessary. 
Maybe somebody could explain us the root cause that led to the FF 22 change in some simple words?
If there were good reasons: Maybe there is a way to keep the old behaviour and fix another problem?

Would it make sense that we create a new bug? (I don't necessarily want to do this, since I appreciate your comments and replies here)

Boris Zbarsky [:bzbarsky]

Comment 32

•

11 years ago

> but this not really applicable for us, since we do not set a style at all. 

It's applicable because the HTML5 spec defines that all HTML elements that have an attribute whose name is "hidden" have the "display: none" style.

> Maybe somebody could explain us the root cause that led to the FF 22 change

Sure.  See bug 614825.  We used to implement the HTML5 spec for all elements _except_ <embed> elements.  We removed the exception, since it was not spec-compliant.

Christoph Hipp

Comment 33

•

11 years ago

Thanks a lot. That is interesting.

The page containing the embed element with the hidden attribute does not declare itself to be HTML5.

MHO: If something is not declared as HTML5, it shouldn't necessarily be treated as HTML5, especially if the semantics change. 
bug 614825 uses in the title the word "should" what is not strongest verb/advice.

... considering this...

1) Would it be possible, in the case that a HTML document does not declare HTML5 compatibility, to use the old "FF 21 way" of dealing with the hidden attribute (at least of the embed tag)?
2) HTML5 compatible documents can/should/shall be handled as implemented in FF 22. 

Such an implementation would be perfectly fine for us.

Does this make sense?

Boris Zbarsky [:bzbarsky]

Comment 34

•

11 years ago

HTML5 defines that all documents served as text/html MUST be treated per HTML5.  There is no way to "declare HTML5 compatibility".

That said, it's possible that there is a spec problem here.  Which is why I'd appreciate an answer to comment 30: that would give us a better idea of whether the spec needs changing.

screenshot of nightly 2013-03-06 11 years ago Guillaume Abadie 478.06 KB, image/jpeg		Details
2013-03-06_notworking 11 years ago testing.s3d 1.15 MB, image/png		Details
2013-03-05_working 11 years ago testing.s3d 1.10 MB, image/png		Details