plugin instances should reload when the src/data URL changes

RESOLVED FIXED in Firefox 13

Status

()

defect
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: kdevel, Assigned: jaas)

Tracking

({regression, reproducible})

Trunk
mozilla14
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox12 unaffected, firefox13+ verified, firefox14 verified)

Details

(Whiteboard: [qa+])

Attachments

(1 attachment, 1 obsolete attachment)

User Agent:  

Steps to reproduce:

1. Install and activate flashblock 1.5.15.1, tweak version checking if necessary.
2. Open http://www.youtube.com/watch?v=3fqBuo5JZoY
3. Click at play symbol.


Actual results:

3. Video does not start playing.


Expected results:

3. Start playing.

The first bad revision is:
changeset: 85853:15b00ab7f22d
user: Josh Aas <joshmoz@gmail.com>
date: Tue Jan 31 16:55:54 2012 -0500
summary: Bug 90268: Change plugin instance ownership from layout to content. r=roc r=bsmedberg

Regression: Bug 682951 - Youtube video does not start with flashblock
OS: Other → Linux
Hardware: Other → x86_64
Component: Untriaged → Plug-ins
Product: Firefox → Core
QA Contact: untriaged → plugins
Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120207 Firefox/13.0a1
Mozilla/5.0 (Windows NT 6.1; rv:13.0a1) Gecko/20120215 Firefox/13.0a1

Confirmed with steps from comment 0.
Blocks: 90268
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Josh, can you have a look at this bug? Is it a regression to your fix? This sounds like it might be a bug in the add-on but I'm not sure.
Keywords: regression
Please test with today's nightlies.

Please also test with one of the builds at the following URL, which have my patch for bug 723520:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-292c77354647/
Thanks, Stefan.
I can reproduce this bug, too, on OS X 10.6.8 (testing with today's mozilla-central nightly).  I won't be able to get to it for a while, though.
Assignee: nobody → joshmoz
A little debugging shows that we're starting the plugin instance just fine after clicking to play the video, and, as expected, we're sending an NPP_SetWindow message over IPC. Still not sure why the video doesn't play though.
Very strange. My own self builds work:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120223 Firefox/13.0a1 
But downloaded nightlies from ftp.mozilla.org show this bug.
I can confirm this bug too.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20120223 Firefox/13.0a1
I can confirm this bug too.

Error message:

Error: e.target.ownerDocument is undefined
Source File: chrome://flashblock/content/flashblock.js
Line: 267
Works fine if you add youtube.com to the flashblock whitelist.
(In reply to Ozsmeg from comment #11)
> Works fine if you add youtube.com to the flashblock whitelist.

For example I use flash mainly to stop youtube autoplay so adding it to whitelist dont make sense for me...
agree with tomko222
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120301 Firefox/13.0a1

STR:

1) Install Flashblock and make sure it's enabled by default (I'm using 1.5.15.1)
2) Go to http://www.cbsnews.com/8301-3460_162-57390236/paul-limbaugh-apologized-for-personal-gain/
3) Click "PLAY CBS NEWS VIDEO"
4) Click Flashblock play button

Expected: video plays
Occurs: black box where Flash player is
The issue is happening in reverse on dailymotion, video's are playing back when flashblock is enabled, no white listing has been set.
Duplicate of this bug: 733703
So whats going on with this, it is a fairly painful regression, particular on a number of tabs that can put the containers memory use past 1GB 

Any potential work around in the go for flashblock itself?, the e.target.ownerDocument is undefined is kind of sus, I haven't seen that on any of the affected sites i visit.
Neil suggested that I might need e.originalTarget in Flashblock instead but I'll need a reproducible test case to work on.
Error: e.target.ownerDocument is undefined
Source file: chrome://flashblock/content/flashblock.js
Line: 267

when clicking the flashblock overlay on http://www.watchanimeon.com/naruto-shippuden-episode-253/
Error: e.target.ownerDocument is undefined
Source file: chrome://flashblock/content/flashblock.js
Line: 267

when clicking the flash overlay on http://www.youtube.com/watch?v=JLdB0WEixjM

the watchanimeon flash video loads
the youtube video doesn't :|
So is flashblock going to be fixed?

Firefox 13 is in aurora channel and problem is still there.
Keywords: reproducible
I did some debugging on Linux (FC16, trunk code) and here is what I think is going on.

After clicking the play button from Flashblock, the DOM node for the plugin instance is added to the document. It has a useless src/data attribute, about:home or about:blank (I don't remember). As a result of adding this node to the document we instantiate a plugin and kick off a stream for the useless src/data URI. Later on Flashblock fixes the src/data attribute on the instance DOM node. This calls nsObjectLoadingContent::LoadObject, which attempts to re-load the object since the URI is now different. The result is a call to nsObjectLoadingContent::AsyncStartPluginInstance, which returns early doing nothing because we already have an instance. Thus the real stream is never delivered to the plugin.

It would be best if the src/data attribute was set properly when the DOM node was added back to the document so the first instantiation was correct. I'm not sure if we ever supported reloading instances when the src/data URL changed, but that is the fix we'll probably have to make on our end if we need to.
Posted patch fix v1.0 (obsolete) — Splinter Review
> After clicking the play button from Flashblock, the DOM node for the plugin instance is
> added to the document. It has a useless src/data attribute, about:home or about:blank
> (I don't remember). As a result of adding this node to the document we instantiate a
> plugin and kick off a stream for the useless src/data URI. Later on Flashblock fixes
> the src/data attribute on the instance DOM node.

I had to do this because a null src attribute causes OS/2 to crash. See the following snippet from flashblock.xml:

function flashblockSetTitle(current, placeholder, isStandalone) {
	// non-null "about:blank" value to prevent OS/2 crashing
	var fakeURI = "about:blank";
(In reply to Josh Aas (Mozilla Corporation) from comment #24)
> Created attachment 607942 [details] [diff] [review]
> fix v1.0

Works like a charm, thx!
Attachment #607942 - Attachment is obsolete: true
Attachment #608057 - Flags: review?(benjamin)
Comment on attachment 608057 [details] [diff] [review]
fix v1.1 (add a test)

Stealing review, r=jst
Attachment #608057 - Flags: review?(benjamin) → review+
Try build fixed the issue for me.  Youtube, and the cbs new link from comment #14 now work as expected. 

Tested with Flashblock 1.5.16a2 latest 'unstable' developers build on win7 x64, win32 build
i don't have time to check myself (my line is in the process of being repaired)
but can someone verify the chia player, dailymotions on site player (not the embed one) and the flash uploader for dailymotion?
Comment on attachment 608057 [details] [diff] [review]
fix v1.1 (add a test)

[Approval Request Comment]
Regression caused by (bug #): 90268
User impact if declined: Flasblock broken on high profile sites (YouTube), other web compat issues w/o Flashblock.
Testing completed (on m-c, etc.): Automated test checked in.
Risk to taking this patch (and alternatives if risky): 4/10
String changes made by this patch: None
Attachment #608057 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/d85d2f90b632
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
if this patch works without regressions i guess it should be back ported to gecko 13
I guess the problem was with firefox. I tried looking at the patches to see what was wrong but couldn't make sense of it.

Would someone explain to a non-programmer what the problem was and how the patch fixes it?
Comments #23 and #25 explain the issue.
Yes i've read the thread.

From what i can tell when the user wants to unblock the flash object, the flashblock addon changes the flash object address to trigger a flash object refresh from browser.

This has always worked in firefox until firefox 13. So i'm wondering what happened in firefox 13 that broke flashblock and how does the patch fix it?
(In reply to yiaghyku from comment #38)
> So i'm wondering what happened in firefox 13 that broke flashblock...

Read bug 90268
Comment on attachment 608057 [details] [diff] [review]
fix v1.1 (add a test)

[Triage Comment]
Since the risk evaluation here does not yet warrant considering backing out bug 90268, and this bug is critical to fix for our Flashbock users, let's land on Aurora 13.
Attachment #608057 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
If you could also add the qawanted keyword with any testing that we can do to lower that 4/10 risk rating, it'd be greatly appreciated :)
Duplicate of this bug: 728576
Summary: Flash video does not play when flashblock is installed → plugin instances should reload when the src/data URL changes
Whiteboard: [qa+]
Depends on: 747055
Verified that YouTube and cbs videos play as expected on Firefox 13 beta 2 when Flashblock 1.5.15.1 and Flashblock 1.5.16a2 are installed.

Tested on Windows 7, Ubuntu 11.10 and Mac OS x 10.6 using the STR from the description and from Comment 14.

Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0
Verified on Firefox 14 beta 7 that the videos from YouTube and CBS play properly - used the STR from the Description while Flashblock 1.5.15.1 and Flashblock 1.5.16a2 were installed.

Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0
Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20100101 Firefox/14.0
You need to log in before you can comment on or make changes to this bug.