129844 - Elements appear in wrong place when changing top/left

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[José Jeria]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
Gecko/20020308
BuildID:    20020308

Positioning elements using other elements offsetTop/offsetLeft does not work as
expected. 
The element that you want to position first appears for a milisecond on the top
(or left part) of the screen and then it moves to the correct position.
Think that this is a regression. If i am not mistaken this did not happend with
Netscape 6.1

Reproducible: Always
Steps to Reproduce:
1. Run testcase
2. Mouseover link
3. You see the table in top of the page for a milisecond and then it moves to
the correct position.

If you press reload this will often not happen again, but press SHIT + reload
and you will see the problem again.

Comment 1

[José Jeria]

Attachment: -

Comment 2

[José Jeria]

Attachment: New testcase using DIV instead. Setting left and top for a TABLE is broken.

Comment 3

[Christine Hoffman]

Changing QA contact

Comment 4

[José Jeria]

Changing to severity major, this is extremly annoying when you have a lot of
menus for example. And it makes Mozilla look really bad.

Comment 5

[Kevin McCluskey (gone)]

I see the problem using 2002032203 build on WinXP. 

Comment 6

[José Jeria]

Maybe this has nothing to do with offsetTop and offsetLeft, because this site
uses a different solution, but with the same result, the menues appear for a
milisecond to the left
http://www.mtv.com/onair/20anniversary/testimony/

Comment 7

[José Jeria]

Forgot to mention, again, only the first time this happends, press shift +
reload to see bug again.

Comment 8

[José Jeria]

Attachment: Testcase not using offsetTop

I looked into the MTV:s code and they use document.body.offsetWidth to place
out the menu (not 100% sure though). Setting the top and left to a value works
fine, the problem appears when you add it to calculated value.

Comment 9

[Bob Clary [:bc] (inactive)]

using Windows NT 5.0; rv:1.1b Gecko/20020730

can not reproduce problem in testcase 1
can reproduce problem in testcase 2

using Windows NT 5.0; rv:1.0.1 Gecko/20020801 Netscape/7.0 
and   Windows NT 5.0; rv:1.0.1 Gecko/20020730

can not reproduce either testcase 1 or 2

Comment 10

[José Jeria]

If you cant reproduce the testcases with 1.1b, press shift and reload and you
will easily reproduce it. Dont have either Netscape 7 or 1.0.1 installed, by the
URL (mtv.com) attached to this bug is always easily reproduced.

Comment 11

[Doron Rosenberg (IBM)]

Note that the testcase on m1.0.1 doesn't seem to show the issue. 
http://www.mtv.com/onair/20anniversary/testimony/ hower, still does.

Comment 12

[José Jeria]

Component: Keyboard Navigation?

Comment 13

[José Jeria]

All testcases can be reproduced with Netscape 7 final

Comment 14

[djk]

I see the problem with both testcases on w98, build 2002092508

Comment 15

[Doron Rosenberg (IBM)]

I don't see the problem anymore using 2002110404 (trunk) win2k.

Comment 16

[José Jeria]

With build 2002110504, Windows XP I can easily reproduce this. If you dont see
this, then simply press SHIFT + reload and you will see the bug. If you still
cannot reproduce this, maybe it only affets slower systems?

Also this affects the menues at Brainjar:
http://www.brainjar.com/dhtml/menubar/demo.html

See bug 136549 for more info.

Comment 17

[Susie Wyshak]

I reproduced the MTV example.
It happens while the page is still loading and you mouse over the menus. Once
the page is fully loaded the drop downs work normally.

I'm on a DSL connection using the 11/4 commercial branch on Win2k

Comment 18

[Jaime Rodriguez, Jr.]

Nominating for nsbeta1 and topembed as this is effecting top sites.

Comment 19

[Doron Rosenberg (IBM)]

ok, I guess my box to fast, I can see this a bit if I make my cpu load go to 90%.

Comment 20

[Chris Nalls]

Marking topembed+ as part of topembed triage

Comment 21

[Kevin McCluskey (gone)]

-> Karnaze

Comment 22

[karnaze (gone)]

I can't reproduce this (and yes I tried SHIFT + reload multiple times) on the
test case or url. I put some debug code in various paint methods and did not see
that the absolutely positioned div or its text in the test case was painting in
the wrong position. If someone can construct a test case that will fail on a
faster system that would help. I'm removing the testcase keyword and adding
qawanted.

Comment 23

[Rick Ju]

Worksforme, both on 
 mozilla trunk on linux
and 
 netscape7 on solaris (500M cpu, 90% load)

Comment 24

[José Jeria]

I can reproduce this on 3 machines:
 - Windows XP, PII, 400 Mhz
 - Windows 2000, PIII, 500 Mhz
 - Mac OS 9, G4

About producing a testcase that also shows on faster systems. I really dont know
how that testcase should look, and also I cant test it, cause we dont have any
faster computers here than the ones mentioned above.

I will try this at home, with a AMD XP 1900+ and Gerfore 2 card. 

By the way, cant you change the cpu load to 70-80%?

Comment 25

[Christopher Cook]

Can' reproduce this with the given testcase on my system : (PII-350 64MB Win98
Moz Nightly) but I have seen the effect more pronounced at
http://www.brainjar.com/dhtml/menubar/demo3.html
-just noticed Jose mentioned the brainjar menu demo before but demo3 is the one
which exhibits the problem for me..

Comment 26

[karnaze (gone)]

I can see the problem at http://www.brainjar.com/dhtml/menubar/demo3.html on my
win2k m1.0 optimized branch (not sure when it was built) but not on my 11/21/2
win2k debug trunk.

Comment 27

[José Jeria]

Now I also tested on my AMD XP 1900´+ machine at home. And I couldnt reproduce 
the bug, so it only affects slower systems I guess? See comment 24.

Comment 28

[Carine Held]

Reproduced bug on several trunk and branch builds, both on OS X and Win 2K.
Clean test case attached.

Comment 29

[Carine Held]

Attachment: Clean test Case

Comment 30

[Rick Ju]

i still can't see it on this testcase

trunk build for linux ( Gecko/20021209 )

Comment 31

[Kevin McCluskey (gone)]

-> Kin

Comment 32

[Susie Wyshak]

Hey this seems to be fixed on the trunk for me too (12/12 build on Win2K).

The MTV site is fixed + an internal Netscape site we're working on WFM on this
trunk build, and both are broken on 11/20 branch.

This is *great.* Mark fixed?

Comment 33

[Kevin McCluskey (gone)]

WFM: Using 2003012804 build on WinXP.

Comment 34

[José Jeria]

I can still reproduce every testcase attached to this bug. The MTV site is
though working, but that was just an url illustritaing the bug.

As mentioned many times this bug mainly affect SLOWER computers, I see this on
both my Pentium II, 400 Mhz, and my Pentium III, 500 Mhz.

At home I have a faster computer and I never been able to reproduce this. So its
pointless to test this with a newer/faster machine. 
Would be interesting if the people that reproduced this (comment 19, comment 26
and comment 28) can test this again.

Comment 35

[Kevin McCluskey (gone)]

I can reproduce the problem on http://www.mtv.com/onair/20anniversary/testimony/
with Netscape 7.01. But I can not reproduce the problem on the same machine
using a current trunk build. 750Mhz AMD, running WinXP.

Comment 36

[José Jeria]

Anothre link where I see this on my SLOW computer
http://www.competence-site.de/

Though i haven't checked the source to see if they calculate the positions of
the menues.

Comment 37

[Bob Clary [:bc] (inactive)]

Attachment: Clean test Case (#2, Standards, mouseover/out)

This test case is an adaptation from the previous Clean test Case attachment
109660 [details].

It has Standards mode and proper string based assignments to the
HTMLElement.style.[top|left] properties which I noticed "can" make the effect
appear more often on a faster machine.

Since the effect appears to be cache related and can not always be reproduced,
I added a mouseout handler to hide the element and then reset the left/top to
'0'  to show the effect more consisently.

To see the effect, move your move repeatedly over the link and see the flicker.
This is reproducible on a 1Ghz machine. It appears that there is a bit of a
race where the element position is changed via the DOM, and the setting of the
element's visibility and where the element is drawn.

Comment 38

[Susie Wyshak]

For the record, Bob came up with the testcase because this bug affected the
DevEdge website as we were developing it. We had to come up with a workaround.

I was always able to reproduce it if my cache was cleared. Once cached, it
doesn't occur but it was really noticeable and annoying.

Comment 39

[Kevin McCluskey (gone)]

Taking bug for now.

Comment 40

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I never see this on Linux, although I'm on a 1.2GHz Athlon.

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Kevin, I suspect this is an event ordering problem. Probably we're processing a
paint event between the style change and the reflow.

Comment 42

[Kevin McCluskey (gone)]

The flicker is caused by a the synchronous painting of status bar updates. Here
is the stack which leads to the flicker:

nsViewManager::Composite(nsViewManager * const 0x02dd88b8) line 1465
nsViewManager::EnableRefresh(nsViewManager * const 0x02dd88b8, unsigned int 2)
line 3220
nsViewManager::EndUpdateViewBatch(nsViewManager * const 0x02dd88b8, unsigned int
2) line 3251 + 19 bytes
PresShell::FlushPendingNotifications(PresShell * const 0x02d8a780, int 1) line 5077
nsXULDocument::FlushPendingNotifications(nsXULDocument * const 0x02d5e2a0, int
1, int 1) line 2449
nsContentTreeOwner::SetStatus(nsContentTreeOwner * const 0x012a1e34, unsigned
int 3, const unsigned short * 0x0012e908) line 382
nsWebShell::OnOverLink(nsWebShell * const 0x031f6eb0, nsIContent * 0x0324aa40,
nsIURI * 0x033a9e00, const unsigned short * 0x0012ebf0) line 640 + 47 bytes
nsGenericElement::TriggerLink(nsIPresContext * 0x031d7850, nsLinkVerb
eLinkVerb_Replace, nsIURI * 0x02e633e8, const nsAString & {...}, const
nsAFlatString & {...}, int 0) line 3023
nsGenericHTMLElement::HandleDOMEventForAnchors(nsIContent * 0x0324aa40,
nsIPresContext * 0x031d7850, nsEvent * 0x0012eee4, nsIDOMEvent * * 0x0012eea4,
unsigned int 2, nsEventStatus * 0x0012ef2c) line 1579 + 45 bytes
nsHTMLAnchorElement::HandleDOMEvent(nsHTMLAnchorElement * const 0x0324aa40,
nsIPresContext * 0x031d7850, nsEvent * 0x0012eee4, nsIDOMEvent * * 0x0012eea4,
unsigned int 2, nsEventStatus * 0x0012ef2c) line 359
nsGenericDOMDataNode::HandleDOMEvent(nsGenericDOMDataNode * const 0x0324ae40,
nsIPresContext * 0x031d7850, nsEvent * 0x0012eee4, nsIDOMEvent * * 0x0012eea4,
unsigned int 7, nsEventStatus * 0x0012ef2c) line 831 + 40 bytes
nsEventStateManager::DispatchMouseEvent(nsIPresContext * 0x031d7850, nsGUIEvent
* 0x0012f75c, unsigned int 331, nsIContent * 0x0324ae40, nsIFrame * 0x031fe5ac,
nsIContent * 0x0331cdb0) line 2437
nsEventStateManager::GenerateMouseEnterExit(nsIPresContext * 0x031d7850,
nsGUIEvent * 0x0012f75c) line 2573
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x0118e850,
nsIPresContext * 0x031d7850, nsEvent * 0x0012f75c, nsIFrame * 0x031fe5ac,
nsEventStatus * 0x0012f554, nsIView * 0x0324b750) line 376
PresShell::HandleEventInternal(nsEvent * 0x0012f75c, nsIView * 0x0324b750,
unsigned int 1, nsEventStatus * 0x0012f554) line 6205 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x0322b45c, nsIView * 0x0324b750,
nsGUIEvent * 0x0012f75c, nsEventStatus * 0x0012f554, int 0, int & 1) line 6134 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x033ce610, nsGUIEvent * 0x0012f75c, int 0)
line 2214
nsView::HandleEvent(nsViewManager * 0x03411448, nsGUIEvent * 0x0012f75c, int 0)
line 304
nsViewManager::DispatchEvent(nsViewManager * const 0x03411448, nsGUIEvent *
0x0012f75c, nsEventStatus * 0x0012f658) line 1946 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f75c) line 83
nsWindow::DispatchEvent(nsWindow * const 0x033ce6cc, nsGUIEvent * 0x0012f75c,
nsEventStatus & nsEventStatus_eIgnore) line 1115 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f75c) line 1136
nsWindow::DispatchMouseEvent(unsigned int 300, unsigned int 0, nsPoint *
0x00000000) line 5376 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, unsigned int 0, nsPoint *
0x00000000) line 5633
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 10944675, long *
0x0012fbf0) line 4067 + 28 bytes
nsWindow::WindowProc(HWND__ * 0x000e03b4, unsigned int 512, unsigned int 0, long
10944675) line 1402 + 27 bytes
USER32! 77d43a5f()
USER32! 77d43b2e()
USER32! 77d43d6a()
USER32! 77d43dd0()
nsAppShellService::Run(nsAppShellService * const 0x0113c808) line 480
main1(int 1, char * * 0x002b1c20, nsISupports * 0x00afad88) line 1273 + 32 bytes
main(int 1, char * * 0x002b1c20) line 1636 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e7eb69()


During the mouse move the status bar update causes a synchronous paint of the
window before the element is positioned.

Comment 43

[Kevin McCluskey (gone)]

Looks like this bug was introduced by the checkin for bug 97227 which made
status bar updates paint synchronously.

Comment 44

[Kevin McCluskey (gone)]

As I expected, the testcase doesn't blink when it is run within mfcembed because
it does not use XUL.

Clearing (+) on topembed for reconsideration since this problem is specific to
Mozilla. 

Comment 45

[Kevin McCluskey (gone)]

Attachment: Prevent status bar updates from painting synchronously

Comment 46

[Kevin McCluskey (gone)]

The synchronous status bar painting was introduced to fix bug 97380 so that the
Starting Java... would be displayed before starting to load Java. According to
[e-mail] the "Starting Java..." message was removed by the fix for
bug 106411 so it looks like the main motivation for synchronously painting the
status bar has been removed.

If status bar updates for plugins needs to be synchronous, the plugin code
should force a synchronous paint for the invalidated areas before launching the
Java plugin instead of forcing *all* status bar updates to be synchronous.

In addition, bug 135305 requires the status bar updates to be asynchronous.
According to bug 135305, I.E batches all of the status bar updates, so the patch
I attached should fix this bug as well.

Comment 47

[kinmoz]

Comment on attachment 120122 [details] [diff] [review]
Prevent status bar updates from painting synchronously

sr=[e-mail]

Comment 48

[Juan José Mata]

topembed triage: minusing nomination based on Kevin's comment 46.

Comment 49

[Kevin McCluskey (gone)]

Comment on attachment 120122 [details] [diff] [review]
Prevent status bar updates from painting synchronously

John can you review? thanks!

Comment 50

[Johnny Stenback (:jst)]

IIRC there was a reason for making FlushPendingNotifications() do synchronous
paints, something about the status bar updating while the Java plugin is
initializing (which takes forever). Won't this break that? Shouldn't we make
nsContentTreeOwner::SetStatus() not flush paints when mousing over a link in stead?

Comment 51

[Kevin McCluskey (gone)]

see comment 46

Comment 52

[Johnny Stenback (:jst)]

Ah, gotcha, sorry for not reading more of this bug before opening my mouth...

Comment 53

[Kevin McCluskey (gone)]

Fix checked in.