Last Comment Bug 29429 - Clicking in textbox or on a link moves content
: Clicking in textbox or on a link moves content
Status: VERIFIED FIXED
[PDT-], block max size
: top100
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 All
: P1 major with 1 vote (vote)
: M16
Assigned To: buster
: ckritzer (gone)
Mentors:
http://www.yahoo.com
: 30006 (view as bug list)
Depends on:
Blocks: 28553
  Show dependency treegraph
 
Reported: 2000-02-27 07:33 PST by Jerry Baker
Modified: 2002-05-27 14:55 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Watch it for yourself (34.38 KB, image/gif)
2000-02-27 07:46 PST, Jerry Baker
no flags Details
Simplified testcase... (743 bytes, text/html)
2000-03-06 11:59 PST, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details
reduced from excite search (174 bytes, text/html)
2000-05-09 12:41 PDT, karnaze (gone)
no flags Details

Description Jerry Baker 2000-02-27 07:33:58 PST
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 2000-02-27 07:46:09 PST
Created attachment 5815 [details]
Watch it for yourself
Comment 2 Jacob Kjome 2000-02-28 10:24:37 PST
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) 2000-02-28 17:48:42 PST
Pierre, this sounds like an unnecessary reflow. 
Comment 4 Jerry Baker 2000-02-29 22:25:33 PST
Adding top100 keyword.
Comment 5 Andy Grover 2000-02-29 23:44:05 PST
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 2000-03-03 08:32:52 PST
Changing summary field to fit newer cases.
Comment 7 Jerry Baker 2000-03-03 08:36:57 PST
Apologizing much for the spam. Forgot to set component when updating summary 
field.
Comment 8 scott 2000-03-03 09:35:07 PST
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 2000-03-03 10:30:55 PST
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 2000-03-06 08:03:20 PST
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) 2000-03-06 11:56:28 PST
The real problem is related to incremental reflow in tables (jst@netscape.com 
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) 2000-03-06 11:57:27 PST
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, jst@mozilla.com) 2000-03-06 11:59:57 PST
Created attachment 6167 [details]
Simplified testcase...
Comment 14 Johnny Stenback (:jst, jst@mozilla.com) 2000-03-06 12:04:09 PST
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 2000-03-06 17:16:00 PST
Putting on PDT+ radar for beta1.
Comment 16 scott 2000-03-07 08:19:26 PST
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) 2000-03-07 14:33:02 PST
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 2000-03-07 16:53:36 PST
As noted by attinasi@netscape.com, 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 2000-03-08 00:50:38 PST
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 2000-03-08 13:38:44 PST
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 2000-03-08 14:19:13 PST
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) 2000-03-09 00:54:42 PST
Fixed.
Comment 23 shrirang khanzode 2000-03-09 14:11:55 PST
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 2000-03-10 13:40:31 PST
shrir@netscape.com: 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 2000-03-10 17:30:56 PST
Verified with 2000-03-10-13.
Comment 26 karnaze (gone) 2000-03-14 17:02:14 PST
*** Bug 30006 has been marked as a duplicate of this bug. ***
Comment 27 Prashant Desale 2000-03-15 13:27:27 PST
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 2000-03-15 13:33:13 PST
Yes, I see this problem on today's windows and mac beta1 commercial bits.
Comment 29 karnaze (gone) 2000-03-15 14:24:31 PST
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 2000-03-15 23:10:44 PST
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 2000-03-16 08:15:01 PST
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 2000-03-16 08:53:54 PST
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 2000-03-16 16:45:42 PST
marked worksforme per rickg and pdt
Comment 34 Claudius Gayle 2000-03-16 16:55:27 PST
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 2000-03-16 23:07:33 PST
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 2000-03-16 23:11:13 PST
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) 2000-03-17 12:15:37 PST
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 2000-03-17 12:20:30 PST
maybe a good time to learn how to use VerifyReflow, it might help you track down 
what frames are misbehaving.
Comment 39 ckritzer (gone) 2000-03-17 14:14:40 PST
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) 2000-03-17 14:17:57 PST
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 2000-03-18 22:00:07 PST
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 2000-03-20 11:52:15 PST
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) 2000-03-20 13:57:19 PST
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 2000-03-20 16:37:40 PST
No longer jumping on many top 100 sites with Mar20 builds.  Setting to PDT-.
Comment 45 karnaze (gone) 2000-05-07 11:58:34 PDT
An incremental reflow problem.
Comment 46 rods (gone) 2000-05-08 07:45:25 PDT
reassigning
Comment 47 karnaze (gone) 2000-05-08 08:44:41 PDT
I think this a table incremental reflow problem. Reassigning to myself.
Comment 48 karnaze (gone) 2000-05-09 12:41:22 PDT
Created attachment 8477 [details]
reduced from excite search
Comment 49 karnaze (gone) 2000-05-09 12:46:02 PDT
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 2000-05-09 12:58:43 PDT
escalating based on number of effected sites.
Comment 51 buster 2000-05-13 22:04:28 PDT
fixed incremental calculation of preferred size in nsBlockFrame and 
nsBlockReflowContext
Comment 52 ckritzer (gone) 2000-07-17 08:37:25 PDT
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 2002-05-27 14:31:04 PDT
Mass removing self from CC list.
Comment 54 Jerry Baker 2002-05-27 14:55:45 PDT
Now I feel sumb because I have to add back. Sorry for the spam.

Note You need to log in before you can comment on or make changes to this bug.