Closed
Bug 599476
Opened 14 years ago
Closed 14 years ago
windowless plugins in object elements with data (e.g. certain Flash pages) are not painted
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(blocking2.0 beta7+)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta7+ |
People
(Reporter: playwatch, Assigned: romaxa)
References
()
Details
(Keywords: regression, Whiteboard: [flash])
Attachments
(3 files, 2 obsolete files)
1.10 KB,
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
5.06 KB,
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
1.31 KB,
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre
On some pages flash plugin stopped working
Reproducible: Always
Steps to Reproduce:
1.Go to http://www.youtube.com/user/tippexperience with a fresh profile
2.wait until site is loaded
3.
Actual Results:
Instead of the video there is only a white space
Expected Results:
The video should start
Another page with this issue is http://www.divineproject.altervista.org/.
I'll try to find the latest working build.
Latest Working hourly is 1285098901-20100921125501-81c0aef6b272-firefox-4.0b7pre.en-US.linux-i686.
First Broken hourly is 1285106168-20100921145608-8b252736a650-firefox-4.0b7pre.en-US.linux-i686.tar.bz2.
So this bug it's probably caused by https://bugzilla.mozilla.org/show_bug.cgi?id=598112 patches...
Comment 3•14 years ago
|
||
anyone else seeing this?
Comment 4•14 years ago
|
||
I see it on Vimeo and YTMND
http://vimeo.com/14980662
I can conform the regression range insofar that the Linux x86_64 2010-09-21 nightly works and the 2010-09-22 nightly does not.
Comment 5•14 years ago
|
||
I see this with Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100101 Firefox/4.0b7pre (self-built) on Fedora 13 with both Flash 10.1.85.3 (using nspluginwrapper) and 10.2.161.22, the 64-bit preview.
For me, this issue affects the the Moogalover player used by Vimeo (http://vimeo.com). YouTube videos work OK.
If I set dom.ipc.plugins.enabled to false, the Flash videos appear, though on some sites, i.e. http://www.cartoonbrew.com/, embedded Vimeo videos show as black with a play button on it. On these sites, playing the video gives audio and the player's controls, but the video itself remains black.
I see the same on a windows build that has patches from bug 596451.
Backing out
- if (RUNNING != mRunning)
- return NS_OK;
-
from bug 598112 fixes the issue.
Assignee | ||
Comment 7•14 years ago
|
||
Yep, I see it is reproducible,
> - if (RUNNING != mRunning)
> - return NS_OK;
> -
>
removing this will disable plugin layers implementation....
(In reply to comment #6)
> I see the same on a windows build that has patches from bug 596451.
interesting why this is visible windows build, because plugin layers should not be available on windows
Assignee: nobody → romaxa
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(In reply to comment #5)
> I see this with Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100101
> Firefox/4.0b7pre (self-built) on Fedora 13 with both Flash 10.1.85.3 (using
> nspluginwrapper) and 10.2.161.22, the 64-bit preview.
>
> For me, this issue affects the the Moogalover player used by Vimeo
> (http://vimeo.com). YouTube videos work OK.
>
> If I set dom.ipc.plugins.enabled to false, the Flash videos appear, though on
> some sites, i.e. http://www.cartoonbrew.com/, embedded Vimeo videos show as
> black with a play button on it. On these sites, playing the video gives audio
> and the player's controls, but the video itself remains black.
Vimeo black playback happens even in the latest beta, so it's probably another regression...
Assignee | ||
Comment 9•14 years ago
|
||
Ok, I found where is the problem,
ObjectFrame and PluginInstance created and then PluginInstance immediately destroyed.
After that new PluginInstance created with the same ObjectFrame but CallSetWindow not called and surface not initialized.
I'll fix it soon
Assignee | ||
Comment 10•14 years ago
|
||
Easy way to get that working is press CTRL + and CTRL+0 (force reflow and setWindow call)
Reporter | ||
Comment 11•14 years ago
|
||
I cam make it work by changing the zoom, but animations freeze by right-clicking them.
Reporter | ||
Comment 12•14 years ago
|
||
(In reply to comment #8)
> (In reply to comment #5)
> > I see this with Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100101
> > Firefox/4.0b7pre (self-built) on Fedora 13 with both Flash 10.1.85.3 (using
> > nspluginwrapper) and 10.2.161.22, the 64-bit preview.
> >
> > For me, this issue affects the the Moogalover player used by Vimeo
> > (http://vimeo.com). YouTube videos work OK.
> >
> > If I set dom.ipc.plugins.enabled to false, the Flash videos appear, though on
> > some sites, i.e. http://www.cartoonbrew.com/, embedded Vimeo videos show as
> > black with a play button on it. On these sites, playing the video gives audio
> > and the player's controls, but the video itself remains black.
>
> Vimeo black playback happens even in the latest beta, so it's probably another
> regression...
https://bugzilla.mozilla.org/show_bug.cgi?id=596454
Comment 13•14 years ago
|
||
I see this quite a bit on newgrounds.com/movies and www.youtube.com on friday's nightly build of Fennec on maemo. I'm getting either a blank space or the plugin disabled message.
Keywords: qawanted
Hardware: x86 → All
Updated•14 years ago
|
tracking-fennec: --- → ?
Assignee | ||
Comment 14•14 years ago
|
||
Variant 1, track destroy calls, and call setWindow in BuildLayer if new Instance was installed
Attachment #478673 -
Flags: feedback?(roc)
Assignee | ||
Comment 15•14 years ago
|
||
in non-layers plugin mode, we have SetWindow call coming from DrawWithXlib call because of offset not equals to mPluginWindow->x/y.
This patch is trying to do the same thing
Attachment #478675 -
Flags: feedback?(roc)
Assignee | ||
Comment 16•14 years ago
|
||
Comment on attachment 478673 [details] [diff] [review]
Track call set window after SetInstance call
roc is on vacation
Attachment #478673 -
Flags: feedback?(roc) → feedback?(benjamin)
Assignee | ||
Comment 17•14 years ago
|
||
Comment on attachment 478675 [details] [diff] [review]
another version, check the same what DrawWithXlib cheking
roc is on vacation, benjamin I need your feedback
Attachment #478675 -
Flags: feedback?(roc) → feedback?(benjamin)
Updated•14 years ago
|
Whiteboard: [flash]
Updated•14 years ago
|
blocking2.0: ? → beta7+
Comment 18•14 years ago
|
||
Comment on attachment 478673 [details] [diff] [review]
Track call set window after SetInstance call
This one seems clearer to me. We should really get some sort of peer to review this: karlt/bz/josh?
Attachment #478673 -
Flags: feedback?(benjamin) → feedback+
Assignee | ||
Updated•14 years ago
|
Attachment #478673 -
Flags: review?(karlt)
Comment 19•14 years ago
|
||
There are also issues with Google Maps, as reported in bug 599492 and bug 599493.
Also http://www.norc.at/street-view/ is having Flash related issues.
May they be related to this bug?
Comment 20•14 years ago
|
||
Also seems to affect http://www.cnn.com/video/
Keywords: regression
Summary: Flash does not work on certain pages → Flash content is not painted on certain pages
Comment 21•14 years ago
|
||
Comment on attachment 478675 [details] [diff] [review]
another version, check the same what DrawWithXlib cheking
With non-layer X11 plugins, the first SetWindow always arrives before the first
paint, even with 0 offset, because the visual (and colormap) are 0 until
the first paint.
With non-layer GDI plugins, the first SetWindow always arrives because the HDC
is null until the first paint.
Attachment #478675 -
Attachment is obsolete: true
Attachment #478675 -
Flags: feedback?(benjamin)
Comment 22•14 years ago
|
||
It should be possible to write a simple reftest based on
data:text/html,<object width="200" height="200" data="data:application/x-test,0" drawmode="solid" color="ff00ff00"></object>
Flags: in-testsuite?
Comment 23•14 years ago
|
||
Comment on attachment 478673 [details] [diff] [review]
Track call set window after SetInstance call
Because the plugin is painting asynchronously, I think it would be better to
tell the plugin its size and tell the host we are using layers as soon as possible, rather than at the point where we try to use what it would paint.
This looks like a good place for that,
http://hg.mozilla.org/mozilla-central/annotate/5a2012482a63/modules/plugin/base/src/nsPluginStreamListenerPeer.cpp#l598
which would be more consistent with the currently working
nsObjectFrame::Instantiate(const char* aMimeType, nsIURI* aURI) behavior (as well as more consistent with windowed plugin behavior).
Updated•14 years ago
|
tracking-fennec: ? → ---
Comment 24•14 years ago
|
||
Comment on attachment 478673 [details] [diff] [review]
Track call set window after SetInstance call
This issue here is not that SetInstance is replacing an existing PluginInstance with a new one (which would fire an assertion), but that these object elements use nsObjectFrame::Instantiate(nsIChannel* aChannel, nsIStreamListener** aStreamListener), which, unlike nsObjectFrame::Instantiate(const char* aMimeType, nsIURI* aURI), does not call AsyncSetWindow.
The appropriate fix is to call AsyncSetWindow as indicated in comment 23.
Attachment #478673 -
Flags: review?(karlt) → review-
Updated•14 years ago
|
Summary: Flash content is not painted on certain pages → windowless plugins in object elements with data (e.g. certain Flash pages) are not painted
Assignee | ||
Comment 25•14 years ago
|
||
Attachment #478673 -
Attachment is obsolete: true
Attachment #480136 -
Flags: review?(karlt)
Comment 26•14 years ago
|
||
We really need an automated test for this. Can we do it with a reftest?
Comment 28•14 years ago
|
||
(In reply to comment #26)
> We really need an automated test for this. Can we do it with a reftest?
Yes. Compare a solid green div with
<object width="200" height="100"
data="data:application/x-test,0" drawmode="solid" color="ff00ff00"></object>
Comment 29•14 years ago
|
||
Comment on attachment 480136 [details] [diff] [review]
part 2: Fixd according karl comment
This part is good, but we can't use it until UseAsyncPainting knows about mozilla.plugins.use_layers. I assume testing that pref can be moved to nsNPAPIPluginInstance.
Attachment #480136 -
Flags: review?(karlt)
Assignee | ||
Comment 30•14 years ago
|
||
Attachment #480364 -
Flags: review?(karlt)
Assignee | ||
Comment 31•14 years ago
|
||
Comment on attachment 480136 [details] [diff] [review]
part 2: Fixd according karl comment
I think these two patches make sense now.
Attachment #480136 -
Flags: review?(karlt)
Assignee | ||
Comment 32•14 years ago
|
||
Attachment #480367 -
Flags: review?(karlt)
Comment 33•14 years ago
|
||
Comment on attachment 480364 [details] [diff] [review]
part 1: prefs part
> PRBool UseLayers()
> {
>- return (mUsePluginLayers &&
>+ PRBool useAsyncRendering = PR_FALSE;
No need to initialize useAsyncRendering as there is an NS_SUCCEEDED check.
>+ return (NS_SUCCEEDED(mInstance->UseAsyncPainting(&useAsyncRendering)) &&
>+ useAsyncRendering &&
> (!mPluginWindow ||
> mPluginWindow->type == NPWindowTypeDrawable));
Add a null check for mInstance.
>+ nsCOMPtr<nsIPrefBranch> prefs(do_GetService(NS_PREFSERVICE_CONTRACTID));
>+ if (prefs) {
>+ PRBool useLayersPref = mUsePluginLayersPref;
No need to initialize useLayersPref.
It is only an outparam for GetBoolPref().
Attachment #480364 -
Attachment description: prefs part → part 1: prefs part
Attachment #480364 -
Flags: review?(karlt) → review+
Updated•14 years ago
|
Attachment #480136 -
Flags: review?(karlt) → review+
Comment 34•14 years ago
|
||
Comment on attachment 480367 [details] [diff] [review]
reftest
Thanks!
Attachment #480367 -
Flags: review?(karlt) → review+
Updated•14 years ago
|
Attachment #480136 -
Attachment description: Fixd according karl comment → part 2: Fixd according karl comment
Assignee | ||
Comment 35•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•