Closed Bug 129844 Opened 18 years ago Closed 17 years ago

Elements appear in wrong place when changing top/left


(Core :: Layout, defect, P1, major)






(Reporter: bugzilla, Assigned: kmcclusk)




(Keywords: regression, testcase, topembed-, Whiteboard: TESTCASE)


(6 files)

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

Positioning elements using other elements offsetTop/offsetLeft does not work as
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.
Attached file -
Changing QA contact
QA Contact: petersen → moied
Changing to severity major, this is extremly annoying when you have a lot of
menus for example. And it makes Mozilla look really bad.
Severity: normal → major
Keywords: regression
Ever confirmed: true
Priority: -- → P2
I see the problem using 2002032203 build on WinXP. 
Keywords: mozilla1.0
Target Milestone: --- → Future
Keywords: testcase
Keywords: mozilla1.0mozilla1.1
OS: Windows 2000 → All
Hardware: PC → All
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
Forgot to mention, again, only the first time this happends, press shift +
reload to see bug again.
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.
Summary: Problems using offsetTop and offsetLeft → Elements appear in wrong place when changing top/left
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
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 ( attached to this bug is always easily reproduced.
Note that the testcase on m1.0.1 doesn't seem to show the issue. hower, still does.
Component: Layout → Keyboard Navigation
Component: Keyboard Navigation?
Keywords: mozilla1.2
All testcases can be reproduced with Netscape 7 final
I see the problem with both testcases on w98, build 2002092508
Component: Keyboard Navigation → Layout
Keywords: mozilla1.3
I don't see the problem anymore using 2002110404 (trunk) win2k.

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:

See bug 136549 for more info.
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
Nominating for nsbeta1 and topembed as this is effecting top sites.
Keywords: nsbeta1, topembed
ok, I guess my box to fast, I can see this a bit if I make my cpu load go to 90%.
Marking topembed+ as part of topembed triage
Keywords: topembedtopembed+
-> Karnaze
Assignee: attinasi → karnaze
Keywords: nsbeta1nsbeta1+
Priority: P2 → P1
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
Keywords: testcaseqawanted
Whiteboard: TESTCASE
Worksforme, both on 
 mozilla trunk on linux
 netscape7 on solaris (500M cpu, 90% load)
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%?
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
-just noticed Jose mentioned the brainjar menu demo before but demo3 is the one
which exhibits the problem for me..
I can see the problem at on my
win2k m1.0 optimized branch (not sure when it was built) but not on my 11/21/2
win2k debug trunk.
Target Milestone: Future → mozilla1.3beta
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.
Reproduced bug on several trunk and branch builds, both on OS X and Win 2K.
Clean test case attached.
Keywords: testcase
Attached file Clean test Case
i still can't see it on this testcase

trunk build for linux ( Gecko/20021209 )
-> Kin
Assignee: karnaze → kin
Target Milestone: mozilla1.3beta → mozilla1.4alpha
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?
WFM: Using 2003012804 build on WinXP.
Closed: 17 years ago
Resolution: --- → WORKSFORME
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.
Resolution: WORKSFORME → ---
I can reproduce the problem on
with Netscape 7.01. But I can not reproduce the problem on the same machine
using a current trunk build. 750Mhz AMD, running WinXP.
Anothre link where I see this on my SLOW computer

Though i haven't checked the source to see if they calculate the positions of
the menues.
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[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.
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.
Taking bug for now.
Assignee: kin → kmcclusk
I never see this on Linux, although I'm on a 1.2GHz Athlon.
Kevin, I suspect this is an event ordering problem. Probably we're processing a
paint event between the style change and the reflow.
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.
Target Milestone: mozilla1.4alpha → mozilla1.4beta
Looks like this bug was introduced by the checkin for bug 97227 which made
status bar updates paint synchronously.
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
Keywords: topembed+topembed
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 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.
Blocks: 135305
Comment on attachment 120122 [details] [diff] [review]
Prevent status bar updates from painting synchronously
Attachment #120122 - Flags: superreview+
topembed triage: minusing nomination based on Kevin's comment 46.
Keywords: topembedtopembed-
Comment on attachment 120122 [details] [diff] [review]
Prevent status bar updates from painting synchronously

John can you review? thanks!
Attachment #120122 - Flags: review?(jkeiser)
Attachment #120122 - Flags: review?(jkeiser) → review+
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?
see comment 46
Ah, gotcha, sorry for not reading more of this bug before opening my mouth...
Fix checked in.
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.