Plugins newly exposed area isn't invalidated after scrolling

RESOLVED FIXED in mozilla0.9.8


18 years ago
10 years ago


(Reporter: tarahim, Assigned: bnesse)


({platform-parity, top100})

Mac System 9.x
platform-parity, top100
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments)



18 years ago
There was a bit similar bug 73176 duped to 73406, which has been resolved fixed.
2001041308 Mac trunk.
Goto URL.
After loading is complete, move the scrolling tab up and down.
Result: iframe at the lower left of the window is out of synch, and some parts
never get refreshed.
Expected result: everything in the window should scroll together.

Comment 1

18 years ago
Everything works just fine at this link as far as I can tell with build
2001043004 on win2k


Comment 2

18 years ago
*** Bug 80005 has been marked as a duplicate of this bug. ***

Comment 3

18 years ago
Reassigning to savulov for analysis/triage.
Assignee: karnaze → alexsavulov
this also happens on the front page of it's pretty bad, and needs
to be fixed for beta.

who should get this bug?
Keywords: 4xp, correctness, mozilla0.9.1, nsbeta1, nsmac1, pp, top100
*** Bug 82756 has been marked as a duplicate of this bug. ***
missed some cc's. pulling over from dupe bug.

Comment 7

18 years ago
checked this and found out it happens on flash5 containing pages. continue 
checking with other plug-ins.

Comment 8

18 years ago
Is this a plugin bug or iframe bug? Can someone attach a minimal testcase? 
Hmm...lots of keywords, important...

cc:ing Brian Nesse. I recall you helping fix something similar for RTM.

Comment 9

18 years ago
Reassigned to Peter. I think it has something to do with the UI messages (and 
differences between macOS an windows), i think that some of the events triggered 
on windows are not triggered on mac (plug-in eating important UI messages 
maybe). It does not appear to me that it has something to do with sync... rather 
the painting is not done at all for some regions. Try with different flash5 
containing pages and see how they act. (i tried with,,..) Also see if the flash4 plug-in causes the same bug.
Assignee: alexsavulov → peterlubczynski

Comment 10

18 years ago
Okay, I've simplifed this:

1) Reisze your browser so that it's height is half of normal. 
2) Visit
3) Start to scroll, slowly.

Notice that the plugin bits on the screen are correctly moved up. However, the 
newly exposed plugin area isn't being told invalidate.

One way to debug this would be to attach npspy logs of 4.x and Mozilla in 
scrolling a simple testcase.

Making mozilla0.9.2 as that sounds reasonable.
Chaging summary from: scrolling of iframe out of synch from rest of the window 
Priority: -- → P3
Summary: scrolling of iframe out of synch from rest of the window content → Plugins newly exposed area isn't invalidated after scrolling
Target Milestone: --- → mozilla0.9.2

Comment 11

18 years ago
Did the fix for bug 31032 affect this?

Comment 12

18 years ago
*** Bug 57186 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
I backed out the patch from bug 31032 with no obvious difference in
functionality. The problem appears to lie elsewhere.

Comment 14

18 years ago
This bug has regressed somewhat between the 2001051808 and the 2001052108
builds. In the 2001051808 build, resizing the window or hiding and showing the
window would cause an update to occur. As of the 2001052108 build resizing the
window (larger) does not cause a refresh of the exposed area. Hiding and showing
the window simply leaves a large empty white rectangle where the flash movie
should be. Scrolling around in the small window fails in both cases.

Comment 15

18 years ago
Another regression but I think we have a handel on it. cc:ing Chris Karnaze

If we get a fix, is this beta-stopper, branch material?
Keywords: regression
Whiteboard: [fix-in-hand]
i'd say this was good branch material, but you probably knew that already ;)

Comment 17

18 years ago
Okay, let me know how this patch works on your machine. It's backing out a fix 
for another bug. It should make it like it was before.

Comment 18

18 years ago
Created attachment 37415 [details] [diff] [review]
patches to back out fix for bug 64645
won't backing that out cause other problems to reappear? i'm confused.

Comment 20

18 years ago
Created attachment 37434 [details] [diff] [review]
karnaze's patch (please try)

Comment 21

18 years ago
I've been running with the patch for the past few hours and it looks great on
both Mac and Windows. r=peterl

Seeking super review....
Keywords: patch
Whiteboard: [fix-in-hand] → [need sr= a=]
do i have to apply both patches? running with just the 2nd patch doesn't fix it.
i can't apply both of these patches (i get conflicts), so i'm assuming that they
aren't meant to be applied together.


Comment 24

18 years ago
Damm! Still needs work! Doh..tried a bunch of sites but the actual test URL. 
Whiteboard: [need sr= a=]
foxnews is better, but still not perfect (scrolling with the thumb in realtime
causes some odd jumping on their sidebar when you reach the bottom).
is almost even more broken :( much more jumping while scrolling live.

Comment 26

18 years ago
Try applying this patch freshly:

Should fix and all the rest, but, bug 64645 will be reopned. That
patch backs out the changes. But, that bug isn't anywhere as serious as this, if
we can't have both.

Shouldn't the milestone be mozilla0.9.1?

Whiteboard: [fix-in-hand]
peter, i'm sure i must be doing something different. i applied that last patch
you referenced and rebuilt layout. going to

and scrolling does not look any better (or worse) than it did before. the 10-day
forcast still doesn't repaint correctly.

Comment 28

18 years ago
With Karnaze's patch (attachment 37434 [details] [diff] [review]) I see a distinct improvement. With it
the page only fails to update correctly when it is clipped
horizontally. If you make the window short but wide, it looks great. Same thing
at foxnews is still wacky, even at full width however. I believe
this is definitely a step in the right direction.

Comment 29

18 years ago
Yes, I'm getting similar results trying this again (something was waked last 
night). karanze's patch does seem to make most sites better. However, the 
problems at seem to be there even with completely backing out the 
changes (patch #1). 

I'm reassigning this bug to karnaze as he's on top of it.
Assignee: peterlubczynski → karnaze

Comment 30

18 years ago
Yes, sorry if I didn't make that clear. The bug has always been there. It just
got worse between the bits I referenced. The current patch seems to fix the
additional regresssions. Now we need to locate the original problem.

Comment 31

18 years ago


18 years ago
Whiteboard: [fix-in-hand] → [fix-in-hand]rtm stopper


18 years ago
Blocks: 81362

Comment 32

18 years ago


18 years ago
Blocks: 44322

Comment 33

18 years ago
To avoid confusion, we are trying to get the 1st patch checked in (not the 2nd), 
which will put things back the way they were before the patch in bug 64645 was 
checked in. This is necessary to fix other mac bugs which the patch to bug 64645 
caused (e.g. bug 81362). 

Comment 34

18 years ago
a= for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989

Comment 35

18 years ago
The 1st attachment has been checked in and undoes the patch in bug 64645. Since 
this bug was opened before bug 64645 was checked in, I'm reassigning this to 
bnesse, moving to m0.9.3 and removing "rtm stopper" from the whiteboard.
Assignee: karnaze → bnesse
Whiteboard: [fix-in-hand]rtm stopper
Target Milestone: mozilla0.9.2 → mozilla0.9.3


18 years ago
No longer blocks: 44322
i still think this is an rtm stopper. These top100 sites look like crap, with or
without these patches.
Whiteboard: rtm stopper

Comment 37

18 years ago
Removing some keywords which no longer apply to the current status, timeframe, etc.
Keywords: mozilla0.9.1, patch, regression
Priority: P3 → P2

Comment 38

18 years ago
So the odd thing about this seems to be that the nsObjectFrame gets update
events while the horizontal scrollbar thumb is within 8 pixels of the leftmost
position. Beyond 8 pixels, no update events are ever sent to the nsObjectFrame.

With the vertical scrollbar, update events are sent to the nsObjectFrame
whenever the thumb is within 8 pixels of the top or bottom extent, but nowhere
in between.

Additionally, the events only come when I am moving the scrollbar away from the
end in question, not when I move towards it.

Does this mean anything to anybody? Is 8 pixels a magic number for scrolling?

If anyone wants to try and repro this, I'm currently using
http://slip/shrir/flashedit.html as a testcase because it's a very simple page.


18 years ago
Blocks: 85670

Comment 39

18 years ago
If I turn the number 8 around 45 degrees, it could symbolise the approximate
width of pages with objects (bug 86075, caused by patch in attachment 37415 [details] [diff] [review])

Comment 40

18 years ago
Patch 37415 caused a regression - bug 86075 (All/All, top100, 8 dups, critical
to 0.9.2). Adding a one line patch 39455 cures the regression.

I have no Mac to check if this patch-to-patch regresses this bug or bug 64645.
Could anyone verify that? I asked already Peter Lubczynski for his opinion on
the issue.

Comment 41

18 years ago
There is a tie in to this patch, but not the one that you think. As per my 2001-
06-01 10:43 comments there was a regression from the patch in bug 64645. It 
didn't cause this bug, it simply made it worse by adding another case in which 
the screen failed to update correctly. IIRC either patch attached to this bug 
eliminated that problem, but the one that was checked in also eliminated 2 other 
bugs relating to events not going to plugins.


18 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 42

18 years ago
After going round and round in circles on this for some time now... I'm still
not sure if it is a frame clipping problem, or a widget clipping problem. It
turns out that the 8 pixel thing I mentioned above seems to be a parent of some
sort. The plug-in widget is located at 8,8 in a parent which is 16 pixels larger
than the plug-in. Using the example of a scroll along the horizontal axis. As
long as 1 "x" pixel of the parent is in the visible region, updates are
processed. As soon as that pixel is scrolled out of the visible region, the
nsObjectFrame stops getting paint events... probably because the parent
considers itself totally hidden.

My best guess at this right now is to make the nsObjectFrame a
nsScrollPositionListener (like the CanvasFrame). Unfortunately I believe this is
more of a work around fix than a proper solution.

This really needs to be pursued by someone who has a much better understanding
of the layout engine than I do. Based on the component descriptions, this seems
like it should probably go to the compositor group.
Assignee: bnesse → kmcclusk
Component: Layout → Compositor

Comment 43

18 years ago
*** Bug 93726 has been marked as a duplicate of this bug. ***


18 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Moving to Mozilla0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Reassinging to Peter.
Assignee: kmcclusk → peterl

Comment 46

17 years ago
The testcase no longer shows this bug, but I think it's still happening.
Whiteboard: rtm stopper

Comment 47

17 years ago
Use http://slip/shrir/flashedit.html it still exhibits the undesirable behavior.


17 years ago
Blocks: 104166


17 years ago
Target Milestone: mozilla0.9.6 → mozilla1.0

Comment 48

17 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 49

17 years ago
Taking as this will be fixed by the patch in bug 104445.
Assignee: peterl → bnesse


17 years ago
Depends on: 104445
Target Milestone: mozilla1.0.1 → mozilla0.9.8

Comment 50

17 years ago
Fixed by the checkin for bug 104445.
Last Resolved: 17 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.