Closed Bug 282708 Opened 20 years ago Closed 19 years ago

Plugins appears/flickers for a milisecond in top left corner while page loading

Categories

(Core :: Web Painting, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: roc)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files)

Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217
Firefox/1.0+

When loading the page you will see the quicktime movie will flash for a milisec
in the top left corner of the page. I dont know when this started to happend,
but it does not happend with gecko 1.7.5.

Steps to reprodcue:
1. visit url/testcase and see quicktime movie appear on the top left corner
2. if not, just press reload
Attached file Testcase
This is not reproducable on MacOS X, same build.
Updating summary, also happends with Flash
Summary: Quicktime movies appears/flickers for a milisecond in top left corner while page loading → Plugins appears/flickers for a milisecond in top left corner while page loading
Assignee: nobody → roc
Component: Layout → Layout: View Rendering
QA Contact: layout → ian
mozilla build 20041007 is OK. build 20041028 has this regression. i was testing
with win2k.

http://archive.mozilla.org/pub/mozilla/nightly/ does not have trunk builds
between dates 10-07 and 10-28 :(
Doesn't happen with win2000 2004-10-10 build, happens with win2000 2004-10-12
build. So the fix for bug 238493 seems indeed the most likely candidate for this
regression.
Attached patch possible fix #1Splinter Review
The problem is that we're not really trying to create the plugin in the right
position, and I guess widget change suppression is stopping us from fixing the
position right away after nsObjectFrame::Reflow is done.

Someone should try this patch to see if it fixes the bug. It tries to create
the widget in the right position. I think the code is the right thing to do but
it might not fix the flicker in more elaborate testcases, because often we just
don't know the final position at widget creation time. (Although when it
flickers in more elaborate testcases, it probably would have been flickering
before the widget change changes landed.) A full fix would require suppressing
widget *creation* as well, but that's a lot of tricky work.
I built firefox with this patch and I can confirm that it fixes the issue.
I tested this patch with the build Kai mentions in comment 7 and I can also
confirm that this patch fixes this very visible regression on windows.

Is this safe enough for 1.8b2?
Flags: blocking1.8b2?
Comment on attachment 180322 [details] [diff] [review]
possible fix #1

I think this patch is actually quite safe.
Attachment #180322 - Flags: superreview?(bzbarsky)
Attachment #180322 - Flags: review?(bzbarsky)
Attachment #180322 - Flags: superreview?(bzbarsky)
Attachment #180322 - Flags: superreview+
Attachment #180322 - Flags: review?(bzbarsky)
Attachment #180322 - Flags: review+
Comment on attachment 180322 [details] [diff] [review]
possible fix #1

Simple fix to an annoying visible regression
Attachment #180322 - Flags: approval1.8b2?
Comment on attachment 180322 [details] [diff] [review]
possible fix #1

a=asa
Attachment #180322 - Flags: approval1.8b2? → approval1.8b2+
checked in
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking1.8b2?
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: