482433 - Sibelius Scorch scores don't display or play if Flashblock is active

Status: RESOLVED FIXED

(Camino Graveyard :: Plug-ins, defect)

Description

[Chris Wimlett]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.8pre) Gecko/2009030900 Camino/2.0b3pre (like Firefox/3.0.8pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.8pre) Gecko/2009030900 Camino/2.0b3pre (like Firefox/3.0.8pre)

When opening any of the scores at Sibelius Music the Scorch Logo and icons appear briefly but are then replaced by a grey box.  At this point you should be able to see a score and be able to play through it.  Scorch show up in the list of Camino plug-ins, and in fact the plug-in works fine in Firefox.

Reproducible: Always

Steps to Reproduce:
1.Navigate to http://www.sibeliusmusic.com/
2.Click on one of the red hyper-links - this should open a Scorch score (assuming that the plugin-in is installed), with icons at the top to control playback, etc.

Actual Results:  
A grey box is displayed in place of the score and icons.  Right-clicking in the grey box displays 'About Scorch' - clicking on this displays 'Scorch 5.2.5 Build 30 Scorch Netscape Plugin'.  This is the same version as displayed in Firefox.

Expected Results:  
Display playback, et.c icons then the Scorch score, which can be played back.

Comment 1

[Stuart Morgan]

Given that all the plugin code is core and we now share it all with Firefox 3.0.x, this is much more likely a plugin bug than a Camino bug (assuming the Firefox version you tested with was 3.0.x).

Does it work if you spoof Camino as the appropriate version of Firefox? They may be doing the wrong thing based on UA.

Comment 2

[Chris Wimlett]

I tested this with Firefox 3.1b2.  Excuse my ignorance, but can you tell me how to spoof Camino as Firefox?

Comment 3

[Chris Lawson (gone)]

This works fine for me with a debug build from last night, and has worked fine in Camino trunk builds for quite some time now.

Chris, can you try a fresh profile?

http://pimpmycamino.com/parts/troubleshoot-camino

will help you automate that process.

cl

Comment 4

[Chris Wimlett]

Excellent, thanks Chris - creating a new profile fixed the problem.  I'd not used Scorch for a few weeks so I'm not sure when the problem arose.

Chris

Comment 5

[Chris Lawson (gone)]

You'll want to put back the files from your old profile one by one, re-launching Camino each time, until you find the culprit. I'd be willing to bet it's one of these:

prefs.js
user.js (if it exists)
permissions.sqlite

Alternatively, if the only thing you care about in your profile is your bookmarks, just copy the bookmarks.html file to your new profile (again, while Camino isn't running) and call it good.

Comment 6

[Chris Wimlett]

I think I've found what the problem was.  Everything was fine, until I selected 'Block Flash Animations' in Preferences, then the problem reappeared.  Adding www.sibeliusmusic.com to the flash exceptions list fixed it again (previously I'd only had www.sibelius.com in the list).  I only decided to block flash recently.

Thanks for the other advice - the bookmarks were the only thing I was worried about, so I've managed to get these back OK.

Comment 7

[Chris Lawson (gone)]

That's very strange that Flashblock would cause something that is not Flash to be blocked.

http://www.sibeliusmusic.com/html/sibeliusmusic/view/reformat.js

is the source of the write_scorch function; Philip, do you see anything in there that would cause Flashblock to block non-Flash content?

Comment 8

[Chris Lawson (gone)]

Reopening since there's definitely something screwy going on here.

Comment 9

[Philip Chee]

I think we are tripping up with our broken object detection code which tends to be a bit too aggressive since there are some flash ads that sail close to the edge of valid object syntax in order to avoid detection.

The website uses: type="application/x-sibelius-score"

In the latest flashblock.css we have:

/*
 * Don't bind to activeX objects which Gecko doesn't recognize anyway.
*/
object[type="application/x-oleobject"]
{
 -moz-binding: none !important;
}

Try changing this to:

object:not([type="application/x-shockwave-flash"]):not([type="application/x-director"]):not([type="application/x-authorware-map"])
{
 -moz-binding: none !important;
}

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This looked to me to be a plug-in (re)draw or timing bug (which we've seen before in Cocoa Widgets), but I'll believe Philip ;-)

I can only reproduce this behavior very sporadically in Camino 2.0b2 and Firefox 3.0.7 (with Flashblock on in both cases; never when Flashblock was off), so it'll be a bit hard for me to test that change well.

Chris, were you seeing this very consistently?  If so, you'd be in a much better position to test Philip's theory, and I can upload an updated Flashblock .jar for you to install in Camino and test (after removing Sibelius from the whitelist).

Comment 11

[Philip Chee]

> This looked to me to be a plug-in (re)draw or timing bug (which we've seen
> before in Cocoa Widgets), but I'll believe Philip ;-)

I think we are saying the same thing. For some reason binding XBL to plugin objects tends to trigger layout reflow/frame construction/instantiation bugs in Gecko, even if we aren't doing anything in our constructor.

Hence the |-moz-binding: none !important;|

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

> I think we are saying the same thing. For some reason binding XBL to plugin
> objects tends to trigger layout reflow/frame construction/instantiation bugs in
> Gecko, even if we aren't doing anything in our constructor.
Gotcha.

Does the :not syntax work in Gecko 1.8.1.x?  I seem to remember philippe mentioning something about :not not being supported there.

If this fix does work, and if :not is supported, we might want to take this in the forthcoming Camino 1.6.7 (particularly as we have no friendly whitelisting option in 1.6.x).

Comment 13

[philippe (part-time)]

(In reply to comment #12)
> > I think we are saying the same thing. For some reason binding XBL to plugin
> > objects tends to trigger layout reflow/frame construction/instantiation bugs in
> > Gecko, even if we aren't doing anything in our constructor.
> Gotcha.
> 
> Does the :not syntax work in Gecko 1.8.1.x?  I seem to remember philippe
> mentioning something about :not not being supported there.
Yes, :not() does work in Gecko 1.8.1 and even older, but I don't think you care about those old ones :-).

Note that it may fail if there is an @namespace declaration at the top of the stylesheet. There was an obscure parsing bug with namespace declarations and multiple :not() on older Gecko (pre 1.9). But for flashblock.css, it should work.

Comment 14

[Chris Wimlett]

>Chris, were you seeing this very consistently?  If so, you'd be in a much
>better position to test Philip's theory, and I can upload an updated Flashblock
>.jar for you to install in Camino and test (after removing Sibelius from the
>whitelist).

Yes, it was happening every time I opened a score, so am happy to test an updated Fashblock.jar

Comment 15

[philippe (part-time)]

Attachment: modified flashblock.jar

Modified flashblock.jar, per comment 9. For testing only.

I've only lightly tested this, on youTube and BBC news site. Flash is blocked/unblocked correctly.

(replace the existing one in Camino.app/Contents/MacOS/chrome)

Comment 16

[philippe (part-time)]

Attachment: modified flashblock.jar

I shouldn't have zipped it up... try this one instead.

Comment 17

[Chris Wimlett]

Thanks that seems to have fixed the display problem.  I removed Sibelius from the whitelist and have opened six or seven scores without problems.  A quick check of other sites indicates that Flash is being blocked (or not) correctly.

Only thing is I've now hit the 'blinking score' bug as described on the Sibelius forum at:-

http://www.sibelius.com/cgi-bin/helpcenter/chat/chat.pl?com=thread&start=428885&groupid=3&

Is this being looked at do you know, or should I log it as a separate bug?

Comment 18

[Philip Chee]

Checking in source/content/flashblock/flashblock.css;
/cvs/flashblock/source/content/flashblock/flashblock.css,v  <--  flashblock.css
new revision: 1.10.2.8; previous revision: 1.10.2.7
done

This is what I checked in to the Flashblock CVS:

 /*
- * Don't bind to activeX objects which Gecko doesn't recognize anyway.
+ * Don't bind to objects with an explicit type=""
+ * e.g. type="application/x-sibelius-score".
 */
-object[type="application/x-oleobject"]
-{
- -moz-binding: none !important;
-}
+object[type]:not([type="application/x-shockwave-flash"]):not([type="application/x-director"]):not([type="application/x-authorware-map"])
+{ -moz-binding: none !important; }

Somebody please remember to pull this into Camino.

Comment 19

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #18)
> Somebody please remember to pull this into Camino.

I'll get a patch for this this afternoon; thanks everyone!

Comment 20

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Upgrade to Flashblock 1.5.8-unstable plus this fix

This patch upgrades our Flashblock to the existing Flashblock-unstable (which has a fix for a11y, https://www.mozdev.org/bugs/show_bug.cgi?id=19372) plus the CSS change in comment 18.

Comment 21

[Stuart Morgan]

Comment on attachment 366857 [details] [diff] [review]
Upgrade to Flashblock 1.5.8-unstable plus this fix

sr=smorgan

Comment 22

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Landed in the trunk and MOZILLA_1_8_BRANCH in advance of 1.6.7.

Thanks for the quick fix, Philip.