Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Parts of windowless, transparent nspluginwrapper/Flash plugin not repainted correctly

RESOLVED FIXED in mozilla6

Status

()

Core
Plug-ins
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: cjones, Assigned: karlt)

Tracking

({regression})

unspecified
mozilla6
x86_64
Linux
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 .x+)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

STR
 (1) Load the URL

The little purple ball is painted by the flash instance.  On my gtk2 desktop, I only see the ball drawn when it's between the north and west points of the star.  It's supposed to be drawn all throughout the box, because the applet is at a higher z-index than the star image and background (if I read the source correctly).

3.6 works as expected.
Regression in rendering from 3.6.
blocking2.0: --- → ?
Linux only or not?
Keywords: regressionwindow-wanted
Kevin reports this working correctly on windows in beta10.
Regression range
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8528ce3f97ce&tochange=198709160138
Keywords: regressionwindow-wanted
Perhaps one of Oleg's changesets?
(Assignee)

Updated

7 years ago
Blocks: 598112, 556487
(Assignee)

Comment 6

7 years ago
Works fine here with "Shockwave Flash 10.3 d162".
cjones has 10.1 r102 and nspluginwrapper.
tn are you using nspluginwrapper?
(Assignee)

Updated

7 years ago
Summary: Parts of windowless, transparent plugins not repainted correctly → Parts of windowless, transparent nspluginwrapper/Flash plugin not repainted correctly
(Assignee)

Updated

7 years ago
Depends on: 603397
FTR, with "10.3 d162" the problem goes away.  But, with the WIP patches in bug 626602 with "10.3 d162", the problem comes *back*.
(In reply to comment #6)
> tn are you using nspluginwrapper?

Yes, I _think_ so. Not sure how to check. I have the same version as cjones in comment 6 though.
about:plugins says
File: npwrapper.libflashplayer.so
Should be fixed, but this won't be a priority for 2.0.
blocking2.0: ? → .x
Duplicate of this bug: 631232
Assignee: nobody → karlt
(In reply to comment #7)
> FTR, with "10.3 d162" the problem goes away.  But, with the WIP patches in bug
> 626602 with "10.3 d162", the problem comes *back*.

In case it helps, my patch had made it so that

     if (mIsTransparent && (GetQuirks() & PluginModuleChild::QUIRK_FLASH_EXPOSE_COORD_TRANSLATION)) {

in PluginInstanceChild stopped running, unintentionally.  Fixing that made the bug go away again.
(Assignee)

Comment 13

7 years ago
Thanks.

Does nspluginwrapper pass through the "Shockwave Flash 10.1 r102" in-tact?
i.e. is that what about:plugins says for "Version:"?
From my about:plugins, the complete flash section:

Shockwave Flash

    File: npwrapper.libflashplayer.so
    Version: 
    Shockwave Flash 10.1 r102

MIME Type 	Description 	Suffixes
application/x-shockwave-flash 	Shockwave Flash 	swf
application/futuresplash 	FutureSplash Player 	spl
To answer karlt's IRC question about whether I can invoke the Flash Player context menu on http://www.qwiki.com/q/#!/Finland : Yes, the plug-in's context menu is invokable as usual.

http://www.communitymx.com/content/source/E5141/wmodetrans.htm shows me the same problem that is described in comment 0. In this case, the misclipping is constant. In the qwiki case, the misclipping varies as the swf plays.
FWIW, I'm also seeing this, so if there's anything I can do to help debug, let me know.  In my case, I'm seeing things that feel like this same issue while trying to use embedded video players on Crunchyroll and Hulu.  The videos play fine, but the controls black out when you mouse over them.  Everything works fine in full-screen mode, it only blacks out when viewed embedded within the browser window.
(Assignee)

Updated

6 years ago
Duplicate of this bug: 648454
Bug 648454 contains a description of what is likely the problem here.

Comment 19

6 years ago
Created attachment 526008 [details]
screencast of the reproduction

Just a good reproducer of the issue I see on http://jsbin.tumblr.com/post/4605622638/a-demo-of-the-simple-drag-and-drop-functionality
(Assignee)

Comment 20

6 years ago
Based on Bug 603397 comment 13 and bug 648454, it sounds like this is caused
by the switch from using NP_GetValue to NPPluginFuncs::getvalue for the Flash
NPPVpluginDescriptionString test.
http://hg.mozilla.org/mozilla-central/rev/6bf95d58032e

This was fortunate enough to work fine with Flash Player directly (apparently
because Flash handles both methods the same), but what really confuses
nspluginwrapper is that NPPluginFuncs::getvalue is called (incorrectly) before
newp has been called to construct the instance.
Status: NEW → ASSIGNED
(Assignee)

Comment 21

6 years ago
Created attachment 528261 [details] [diff] [review]
revert to using NP_GetValue

Can you check that this fixes the issue, please Timothy?

GetPluginInfo does more work than necessary but I think it is simpler/tidier
than the platform-specific FindFunctionSymbol, etc., and moving other
platforms to the plugin-based GetPluginInfo rather than the mimetype-based
InitQuirksModes() is probably the way to go in the future.

Currently AddQuirk() and InitQuirksModes() work (awkwardly) with
QUIRKS_NOT_INITIALIZED because they deal with different plugins on X11, but
InitQuirksModes is already awkward with quirk-free plugins initializing to
QUIRKS_NOT_INITIALIZED.
That patch fixes it for me!
(Assignee)

Comment 23

6 years ago
Created attachment 528263 [details] [diff] [review]
revert to using NP_GetValue 1.0.1

Thanks, Timothy.  Updated patch to 1cc4d287d0b8.
Attachment #528261 - Attachment is obsolete: true
Attachment #528263 - Flags: review?(jones.chris.g)
(Assignee)

Comment 24

6 years ago
BTW, I didn't null check .fDescription because nsPluginTag makes the same assumption that it is non-null if GetPluginInfo succeeded.
http://hg.mozilla.org/mozilla-central/annotate/3cdd96a6d372/modules/plugin/base/src/nsPluginTags.cpp#l110
http://hg.mozilla.org/mozilla-central/annotate/1cc4d287d0b8/modules/plugin/base/src/nsPluginTags.h#l112
http://hg.mozilla.org/mozilla-central/annotate/3cdd96a6d372/modules/plugin/base/src/nsPluginHost.cpp#l2289
Comment on attachment 528263 [details] [diff] [review]
revert to using NP_GetValue 1.0.1

>+    // Maemo flash can render plugin with any provided rectangle and not
>+    // require this quirk.

Do you mind fixing the grammar here while you're at it?
Attachment #528263 - Flags: review?(jones.chris.g) → review+

Comment 26

6 years ago
Internesting ... When looking at http://live.twit.tv I see clearly Bitstream (1Mbps), but Bitstream (400 Kbps) is pretty bad.

Comment 27

6 years ago
(In reply to comment #26)
> Internesting ... When looking at http://live.twit.tv I see clearly Bitstream
> (1Mbps), but Bitstream (400 Kbps) is pretty bad.

Yes, I can confirm that with nspluginwrapper-1.3.2-1.fc15 I can play both of these streams without any problems.

Thank you
(Assignee)

Comment 28

6 years ago
(Including grammar touch up:)
http://hg.mozilla.org/mozilla-central/rev/c26ec595c923
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
You need to log in before you can comment on or make changes to this bug.