Clicking in textbox or on a link moves content




18 years ago
16 years ago


(Reporter: Jerry Baker, Assigned: buster)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT-], block max size, URL)


(3 attachments)



18 years ago
When I load Yahoo in build 2000022508 and then click in the textbox to enter 
some search text, all of the page's content above the textbox is shifted 8 
pixels to the left as soon as that textbox receives focus.

Comment 1

18 years ago
Created attachment 5815 [details]
Watch it for yourself

Comment 2

18 years ago
I see this happening on also.  The page loads and 
then as soon as you click on the text box, the whole layout of the page shifts 
over to the left.  I assume it is the 8 pixels that Jerry is talking about.


Comment 3

18 years ago
Pierre, this sounds like an unnecessary reflow. 
Assignee: karnaze → pierre

Comment 4

18 years ago
Adding top100 keyword.
Keywords: top100

Comment 5

18 years ago
I'm also seeing this on whenever I pass the mouse over the "Enter
Zip Code" button down at the bottom.


18 years ago
Summary: Clicking in textbox moves content → Clicking in textbox or on a link moves content

Comment 6

18 years ago
Changing summary field to fit newer cases.

Comment 7

18 years ago
Apologizing much for the spam. Forgot to set component when updating summary 
Component: HTML Form Controls → Layout

Comment 8

18 years ago
I've seen this quite a bit too.  Here's another example:
I'll try to start making note of other pages I find this on.  I've also noticed
some pages that when clicking on a link, instead of following that link, part of
the page gets duplicated and laid over the existing page with a bit of an
offset.  Clicking on the link again in the offset version would then take you to
the link.  I'm not sure if this is related or not, but I saw it on a few
sites... once again, will try and start making notes.

Comment 9

18 years ago
I am the culprit for the reflow that is generated when there is a change in the 

outline. Sorry: it's a very evil fix that meant to be temporary. Look for my 

comment from 2000-01-24 00:24 in bug 9809.

Probably a dup. Reassigned to Vidur who was working on that this week.

Assignee: pierre → vidur

Comment 10

18 years ago
I think I've found an example of the "offset" version of this that I mentioned
earlier (at least, I think it's a version of this bug... maybe this can allow
someone to confirm).  Go to and click on of the 6 links in
the yellow box beneath "Latest Virus Info".  Instead of taking you to the link,
the bottom part of the page shifts up (you'll notice the yellow box shrinks a
bit vertically).  After the shift, you can now click the link again, and
actually be taken there.

Last time I remember seeing this (on a different site), the shift was
horizontal, and a copy of part of the page was superimposed again at an offset,
resulting in a corrupted display (unlike this example, where the page is intact
after the shift).

Comment 11

18 years ago
The real problem is related to incremental reflow in tables ( 
will post a test case for that later). The problem occurs when clicking on links 
because setting the outline property of the link correctly causes a reflow. I'm 
marking this beta1 because I think this is a serious problem (you can make it 
happen by right-clicking on one of the links on I've 
seen it on several pages both left and right clicking. We will get many reports 
about this problem if it isn't fix.

I've included a simple patch that temporarily doesn't do reflows when setting 
the outline property. If the table problem can't be fixed safely or in time, I 
would recommend applying the patch.

Index: nsStyleContext.cpp
RCS file: /cvsroot/mozilla/layout/base/src/nsStyleContext.cpp,v
retrieving revision 3.115
diff -c -r3.115 nsStyleContext.cpp
*** nsStyleContext.cpp  2000/02/17 23:17:36     3.115
--- nsStyleContext.cpp  2000/03/06 19:50:37
*** 766,772 ****
          (mOutlineStyle != aOther.mOutlineStyle) ||
          (mOutlineColor != aOther.mOutlineColor) ||
          (mOutlineRadius != aOther.mOutlineRadius)) {
!       return NS_STYLE_HINT_REFLOW;    // XXX: should be VISUAL: see bugs 9809
and 9816
      return NS_STYLE_HINT_NONE;
--- 766,772 ----
          (mOutlineStyle != aOther.mOutlineStyle) ||
          (mOutlineColor != aOther.mOutlineColor) ||
          (mOutlineRadius != aOther.mOutlineRadius)) {
!       return NS_STYLE_HINT_VISUAL;    // XXX: should be VISUAL: see bugs 9809
and 9816
      return NS_STYLE_HINT_NONE;
Keywords: beta1

Comment 12

18 years ago
Reassigning to karnaze to look at the incremental table reflow bug. If it can't 
be fixed, Pierre should apply the style patch for the outline property.
Assignee: vidur → karnaze
Created attachment 6167 [details]
Simplified testcase...
The testcase I just attached shows how to reproduce this without having a link
even, clicking on the text below the table changes the class on a table cell,
this triggers a reflow and shows the same problem...

Comment 15

18 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]

Comment 16

18 years ago
Another real-world example:

Probably nothing else needed on this but this was one of the original places I
had seen it (severe horizontal shifting, more than 8 pixels, with copy overlaid
on top of original) so I wanted to get it documented... also maybe useful to
test fixes.


18 years ago

Comment 17

18 years ago
This could be a dup of bug 28553 since a reframe reflow is occuring. However, 
the table code needs to be fixed to deal with these extra reflows in general, so 
I'm not going to determine if it is a dup or mark it as such. Adding Buster to 
CC list.

Comment 18

18 years ago
As noted by, this bug appears to be the same as bug 7617,
which I first reported under M6.  I just reopened that bug because I'm seeing
the behavior with middle/right click on links, although I haven't seen it happen
with a left-click for a while.  So, for what it's worth, this is an old bug
rearing its head again.  At least this bug (29429) has more investigation into
the problem.  I just wanted to add a note to this bug to let everyone know that
this bug probably wasn't caused by recent code changes, but started when
incremental reflow was first released...

Comment 19

18 years ago
We should first fix the outline thing as described by vidur (I'll take care of 
it). Then, as noted by deven, this is probably a dup of bug 7617 as well as bug 
28212, more than a dup of bug 28553 as karnaze wrote.

Comment 20

18 years ago
My fix for 28553 does make many of these pages behave correctly.  I agree with 
chris that the fix for 28553 probably masks a serious table incremental reflow 
problem, and that problem should be addressed separately.  This is chris' 
current plan, I'm just agreeing with it and verifying our belief about how the 
two bugs are linked.

Comment 21

18 years ago
IT sounds like you folks have a plan... so please update the status whiteboard.

I'm adding a w/b minus 3/10 to the heading, as I think we will have to release
note this sort of bug if we can't resolve it by then.

PLEASE consider checking in the discussed hack/fix solution RSN ;-)
Whiteboard: [PDT+] → [PDT+] w/b minus 3/10

Comment 22

18 years ago
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] w/b minus 3/10 → [PDT+]


18 years ago
Blocks: 28553

Comment 23

18 years ago
I am unable to click the mouse in the textfield on yahoo or webcrawler web site
 using latest commercial build on windows. Probablythis is due to bug 31176 or 


18 years ago
Whiteboard: [PDT+] → [PDT+] Need a build later than 3/9 to verify

Comment 24

18 years ago I'm not seeing the problem you reported about not being able 
to click in text fields.  Could you retest that with today's commercial 
build and report back here (or directly to me?) thanks.

Comment 25

18 years ago
Verified with 2000-03-10-13.

Comment 26

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

Comment 27

18 years ago
I verified this one on 03-10 and seems like this problem is reoccured.
Instead of page content now text fields are moving.

Probably is best site to reproduce this one.
2] Type something in search textbox [As soon as you type textbox flickers and 
appears to be moved on left side]
3] now after typing click on search button "Google Search". [Again textbox 
4] On next page again click on button "Google search". [This time entire text 
box moves to right.]

BUILDS TESTED: 03-13-18 [wINDOWS-95], Todays Mac commercial build.

Resolution: FIXED → ---

Comment 28

18 years ago
Yes, I see this problem on today's windows and mac beta1 commercial bits.

Comment 29

18 years ago
The original reported problem is fixed (both the url and test case). I wish a 
new bug had been submitted, because now web contributors might believe that 
there is a test case for this bug, but there isn't. 

Comment 30

18 years ago
I just tried to reproduce on Google with today's *beta branch* commercial build,
and I didn't see any movement. (which is what karnaze suggested in his
comments).  Were you testing a branch build, or a trunk build?



18 years ago
Whiteboard: [PDT+] Need a build later than 3/9 to verify → [PDT+]

Comment 31

18 years ago
Jim, I am using the beta branch commercial bits on all platforms. With today's 
ie 03/16 beta bits on windows and linux, I still see the following :

1. Go to
2. Type something in search textbox [As soon as you move mouse towards the 
search button, textbox flickers and appears to be moved on left side]
3 Now, click on the search button "Google Search". [Again textbox 
flickers and appears to move left and towards top also]

However, on today's beta branch builds on windows and linux, I do not see the 
textbox move permamently to the right as was seen on yesterday's bits.

I can reproduce this problem easily. Please drop by if you would like to take a 
look at this. Thanks !
I can

Comment 32

18 years ago
One more easily reproducible test is as follows: 

1. Go to
2. Type some text in the textfield at the center of the page (on top).
3. Move mouse to the SEARCH button (observe that textfield flickers)
4. Press the SEARCH button.
5. Observe that a search results page opens up.
6. Now, just clicking the mouse in the textfield labled "SEARCH FOR" (wherein    
   your earlier search text is present) moves the entire row to the right by 
   say, two character widths.

I see this on both beta1 commercial branch bits for today (03/16) ie, windows 
and linux. Will check mac build when it comes out.

Comment 33

18 years ago
marked worksforme per rickg and pdt
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 34

18 years ago
Ummm, guys I have the 2000031606 WinNT build (comm. beta branch build) and I see
this(on a different machine) EXACTLY as shrirang describes it in the above
comments. Seriously, it's really easy.

I just tried with RH6 Linux 2000031606 (comm. beta branch) and I see mostly the
same results. This is definetly not WFM.
OS: Windows 2000 → All
Resolution: WORKSFORME → ---

Comment 35

18 years ago
Can you list the platforms for which this is still broken?
You mentioned Linux is broken.  Our attempts to demonstrate the problem (at PDT) 
were on Windows boxes (I think).

Comment 36

18 years ago
I should have also added...
We critically need test info for all platforms, on the *beta* branch.
Please focus on that for now.

Comment 37

18 years ago
Using the latest build from (non beta, I guess), I see some shifting 
(about 10 pixels) of the text field on when clicking into it. I'm not 
seeing it on google. I'm not sure what is causing the text box flickering, 
maybe buster or rods knows. Should this really be PDT+?

Comment 38

18 years ago
maybe a good time to learn how to use VerifyReflow, it might help you track down 
what frames are misbehaving.

Comment 39

18 years ago
This seems to be working fine now.  I'm not seeing any of the movement being 
described in the original bug.

Karnaze, if you wanna set it to "Worksforme" I'll set it to verified...

Comment 40

18 years ago

Okay, Mr. Shrirang helped me out here.

It *is* still happening on today's builds.  Sorry Chris.  Please disregard my 
last comments...

Comment 41

18 years ago
To be clear: The PDT+ was granted because the "shift" was roughly an inch, and
caused whole columns of content to be displayed "twice."  If the problem is a 10
pixel shift, then we would not have IMO gone with the PDT+.
As it stands now, we are getting sooooo late in the beta1 game, that it may not
be possible to take any fix in this area.  In genenal, the latest planned fixes
should be tested, approved, and landed by Sunday night.  It will have to be an
incredibly terrible bug to get dispensation beyond that point.

Comment 42

18 years ago
I'd very much like to see info on this bug, and its status.  I suspect we will
release note this item at this afternoon's PDT meeting, but we would like the
most up-to-date info.

Comment 43

18 years ago
Jar, I haven't spent time fixing this bug (a second time) because of the 
confusion surronding it. I'm not sure that it deserves PDT+ status, just because 
it used to be PDT+. 

If you want me to fix this soon, then please tell me so. Otherwise, I may not 
look at it for a few days.

Comment 44

18 years ago
No longer jumping on many top 100 sites with Mar20 builds.  Setting to PDT-.
Whiteboard: [PDT+] → [PDT-]

Comment 45

18 years ago
An incremental reflow problem.
Target Milestone: --- → M16

Comment 46

18 years ago
Assignee: karnaze → beppe

Comment 47

18 years ago
I think this a table incremental reflow problem. Reassigning to myself.
Assignee: beppe → karnaze

Comment 48

18 years ago
Created attachment 8477 [details]
reduced from excite search

Comment 49

18 years ago
Buster, in the 3rd attachment the cell's block is being asked for the max 
element size during an incremental reflow and it is larger than the first time 
it was requested. I commented out the code in the row frame which does this and 
the problem went away. Adding "block max size" to status whiteboard.
Assignee: karnaze → buster
Keywords: beta1
Whiteboard: [PDT-] → [PDT-, block max size

Comment 50

18 years ago
escalating based on number of effected sites.
Severity: normal → major
Priority: P3 → P1


18 years ago
Whiteboard: [PDT-, block max size → [PDT-], block max size, fix in hand

Comment 51

18 years ago
fixed incremental calculation of preferred size in nsBlockFrame and 
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED


18 years ago
Whiteboard: [PDT-], block max size, fix in hand → [PDT-], block max size


17 years ago

Comment 52

17 years ago
- MacOS9 2000-07-14-11-M17 Commercial
- Linux6 2000-07-14-21-M17 Commercial
- Win98  2000-07-14-09-M17 Commercial

Comment 53

16 years ago
Mass removing self from CC list.

Comment 54

16 years ago
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.