29429 - Clicking in textbox or on a link moves content

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Jerry Baker]

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

[Jerry Baker]

Attachment: Watch it for yourself

Comment 2

[Jacob Kjome]

I see this happening on http://www.webcrawler.com 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.

Jake

Comment 3

[karnaze (gone)]

Pierre, this sounds like an unnecessary reflow. 

Comment 4

[Jerry Baker]

Adding top100 keyword.

Comment 5

[Andy Grover]

I'm also seeing this on www.yahoo.com whenever I pass the mouse over the "Enter
Zip Code" button down at the bottom.

Comment 6

[Jerry Baker]

Changing summary field to fit newer cases.

Comment 7

[Jerry Baker]

Apologizing much for the spam. Forgot to set component when updating summary 
field.

Comment 8

[scott]

I've seen this quite a bit too.  Here's another example: http://www.slashdot.org
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

[Pierre Saslawsky]

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.

Comment 10

[scott]

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 http://www.nai.com 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

[vidur (gone)]

The real problem is related to incremental reflow in tables ([e-mail] 
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 http://www.mozilla.org). 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;
    }

Comment 12

[vidur (gone)]

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.

Comment 13

[Johnny Stenback (:jst)]

Attachment: Simplified testcase...

Comment 14

[Johnny Stenback (:jst)]

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

[leger]

Putting on PDT+ radar for beta1.

Comment 16

[scott]

Another real-world example: http://www.eudora.com/

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.

Comment 17

[karnaze (gone)]

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

[Deven Corzine]

As noted by [e-mail], 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

[Pierre Saslawsky]

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

[buster]

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

[Jim Roskind]

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 ;-)
Thanks,
Jim

Comment 22

[karnaze (gone)]

Fixed.

Comment 23

[shrirang khanzode]

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 
31198.

Comment 24

[buster]

[e-mail]: 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

[Prashant Desale]

Verified with 2000-03-10-13.

Comment 26

[karnaze (gone)]

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

Comment 27

[Prashant Desale]

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

Probably http://www.google.com is best site to reproduce this one.
STEPS TO REPRODUCE:
1]Visit http://www.google.com
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 
flickers]
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.

Comment 28

[shrirang khanzode]

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

Comment 29

[karnaze (gone)]

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

[Jim Roskind]

shrir,
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?

Thanks,
Jim

Comment 31

[shrirang khanzode]

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 www.google.com
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

[shrirang khanzode]

One more easily reproducible test is as follows: 

1. Go to www.excite.com
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

[Phil Peterson]

marked worksforme per rickg and pdt

Comment 34

[Claudius Gayle]

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.

Comment 35

[Jim Roskind]

Claudius,
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).
Thanks,
Jim

Comment 36

[Jim Roskind]

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

Comment 37

[karnaze (gone)]

Using the latest build from mozilla.org (non beta, I guess), I see some shifting 
(about 10 pixels) of the text field on 
http://search.excite.com/search.gw?search=travel 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

[buster]

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

Comment 39

[ckritzer (gone)]

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

[ckritzer (gone)]

Oops.

Okay, Mr. Shrirang helped me out here.

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

Comment 41

[Jim Roskind]

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.
Thanks,
Jim

Comment 42

[Jim Roskind]

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.
Thanks,
Jim

Comment 43

[karnaze (gone)]

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

[leger]

No longer jumping on many top 100 sites with Mar20 builds.  Setting to PDT-.

Comment 45

[karnaze (gone)]

An incremental reflow problem.

Comment 46

[rods (gone)]

reassigning

Comment 47

[karnaze (gone)]

I think this a table incremental reflow problem. Reassigning to myself.

Comment 48

[karnaze (gone)]

Attachment: reduced from excite search

Comment 49

[karnaze (gone)]

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.

Comment 50

[buster]

escalating based on number of effected sites.

Comment 51

[buster]

fixed incremental calculation of preferred size in nsBlockFrame and 
nsBlockReflowContext

Comment 52

[ckritzer (gone)]

Marking VERIFIED FIXED on:
- MacOS9 2000-07-14-11-M17 Commercial
- Linux6 2000-07-14-21-M17 Commercial
- Win98  2000-07-14-09-M17 Commercial

Comment 53

[Jerry Baker]

Mass removing self from CC list.

Comment 54

[Jerry Baker]

Now I feel sumb because I have to add back. Sorry for the spam.