Closed Bug 786970 Opened 12 years ago Closed 7 years ago

Windowed plugin content gets displayed out of it's container when scrolling the browser window

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: ioana_damy, Assigned: karlt)

References

Details

Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Firefox/17.0 (20120829042009)

STR:
1. Launch Firefox.
2. Go to http://go-mono.com/moonlight/download.aspx, download and install the plugin. Restart Firefox when requested.
3. Load http://www.vectorlight.net/games/sandmania.aspx in a new tab.
4. Scroll the page horizontally or vertically.

Actual Results:
The plugin content moves outside the container whenever the page is scrolled (scroll bar or mouse wheel).

The content is moving very little (almost not noticeable) on Firefox 4.0 to 12.0. The issue gets much worse from Firefox 13.0.
karlt, do you have cycles to check this out? Moonlight is not a super high priority to me, but I'd like to make sure there's not a more serious cross-platform issue lurking.
Summary: Silverlight content gets displayed out of it's container when scrolling the Linux i686 browser window → Moonlight content gets displayed out of it's container when scrolling the Linux i686 browser window
Also reproducible with Flash content, cross-platform (Flash 11.2 on Linux, Flash 11.4 on Windows).

The difference is that with Flash content the difference between older builds and newer ones is smaller (it scrolls badly on pre-13 builds too).

I will try to find a regression range for this as soon as I get the chance to.
OS: Linux → All
Hardware: x86 → All
Summary: Moonlight content gets displayed out of it's container when scrolling the Linux i686 browser window → Plugin content gets displayed out of it's container when scrolling the browser window
I tried to find a regression range for this bug but I encountered a weird behavior:

When I reproduce this issue on Fx 12 RC, the plugin content moves very little, much less than on Fx 13 RC (as specified in comment 0).

When I tried to reproduce this issue on Fx 12 Nightly and on Firefox 13 Nightly, it reproduced the same on both - the way it works on Fx 13 RC.

This makes finding a regression range quite impossible for me. If anyone else can reproduce this bug, please try to find a regression range for the Fx 13 worsening of this issue.
There has always been (and will be) some inconsistency while scrolling pages with windowed plugins because it is not possible to move the plugin and paint the window at exactly the same time.

However, on trunk I'm seeing things get way out of sync on
http://www.macloo.com/examples/flash/paths/index.htm
This is likely related to bug 787300, so I'm looking at that first.

I'm not certain the behavior in release builds is as intended, and the change in behavior from 12 to 13 indicates something worth investigating.

It is possible the Fx 12 Nightly is reproducing this bug but something was disabled or backed out before the Fx 12 RC.  If so earlier nightlies should demonstrate the earlier behavior and a regression range would still be useful.
Summary: Plugin content gets displayed out of it's container when scrolling the browser window → Windowed plugin content gets displayed out of it's container when scrolling the browser window
(In reply to Karl Tomlinson (:karlt) from comment #4)
> However, on trunk I'm seeing things get way out of sync on
> http://www.macloo.com/examples/flash/paths/index.htm
> This is likely related to bug 787300, so I'm looking at that first.

It's not bug 787300.
Trunk behavior has laggy non-plugin painting irrespective of viewmanager.refresh-driver-painting.enabled

At least with viewmanager.refresh-driver-painting.enabled set, that sounds related to calling DidPaint (which moves plugins) when painting to retained layers, but not compositing to the window.

roc suggested adding Will/DidComposite to shadow Will/DidPaint, and separating what needs to be done at each stage.

That would suggest though that we are painting more frequently than compositing.
Assignee: nobody → karlt
Blocks: dlbi
I can't reproduce on Windows after the re-landing of DLBI.
The changes that have just landed in bug 626245 fix the regression where this got much worse before 17 branched.

I wonder how the next nightly's behavior will compare to that of 12.
Depends on: 626245
Is it smooth scrolling (Preferences -> Advanced) that caused the behavior change between 12 and 13?
Tested on the 10/16 Nightly:
Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/19.0 Firefox/19.0.

On the 10/16 Aurora and on Firefox 17b1, the plugin content bounces very much out of it's container for all the test cases. 

On Nightly, the plugin content is still shaking a little when scrolling.
Blocks: 803793
Ioana, can you please test the difference between smooth scrolling on and off? If so, that would seem to solidify the claim of a regression in Firefox 13.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #10)
> Ioana, can you please test the difference between smooth scrolling on and
> off? If so, that would seem to solidify the claim of a regression in Firefox
> 13.

I checked this on the 14/11 Nightly and it works the same both with smooth scrolling enabled and with it disabled.

I should also mention the fix for bug 626245 solved a lot of this issue, making it much less visible (it's still visible enough not to close the bug though).
After the fix for bug 626245 was pushed, Firefox returned to the behavior it had in Firefox 4 to 12. It is possible that the fix solved the issue that emerged in Firefox 13 and only left the initial smaller one, that is not a regression.
Thanks very much for comparing those versions, Ioana.

It's not possible to make this look absolutely seemless because of the nature of windowed plugins.

Perhaps we can make a small improvement by updating the region to draw after WillPaintWindow to include invalidations that happen when moving the plugin uncovers parts of the content window (bug 626245 comment 67).  This would be moving the gdk_window_get_update_area code in OnExposeEvent.

We may want to make sure that resizes happen during WillPaintWindow, not PaintWindow before doing that.
The DLBI regression here was fixed.
No longer blocks: dlbi
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.