Steps to reproduce: 1) Goto the above url. 2) Watch for the search text field, on the top center, between "Netscape Search" select box and "search" button. 3) On your Preferences adjust the variable-width font to be some large number ..larger than the previous size. Try 40. Actual Result: Text field shifted downwards compared to the select box and the search button. Expected Result: Text field should bottom align with the select box..I think Verify with Nac. 4.x Also, typing on the text field seems to correct the, text field, alignment ( jar does see this happen ).
For me to repro, I need to set the "fixed width font" to be large. But then I see the problem. I tried removing my changes for bug 54005, and this problem went away. Appears to be related to an assertion in ForgetWordFrame(), cf. bug 56073. I'll investigate; at worst, we can revert 54005 and live with the problems that it solved.
Status: NEW → ASSIGNED
Forgot to mention. You should have your "variable-width font" and "fixed-width font" to be of the same size.
So the critical ingredients seem to be a text field 1) that is large enough to force a horizontal scrollbar 2) following an
Simplified repro instructions: 1. Open attached test case 2. Type one character in the text field Expected behavior: nothing happens (well, besides a character appearing in the text field) Actual behavior: text field jumps to a new location!
Created attachment 16845 [details] [diff] [review] fix, check if CanContinueTextRun() when traversing down, too.
*** Bug 54505 has been marked as a duplicate of this bug. ***
*** Bug 56073 has been marked as a duplicate of this bug. ***
Well, don't I just suck. Third time's the charm? :-) I did cause this "regression" when fixing bug 54005. When I moved the termination condition to *before* retrieving the next bug, I exposed this problem: as we traverse down through child frames, we don't check *those* to see if they CanContinueTextRun(). In this case, what was happening was we'd end up with a frame model like so: Block(form)(1)@00D5D0AC < line 00D5D484: < Text(0)@00D5D114 < "blah" > > line 00D5D560: < nsGfxControlFrame2@00D5D150 < GfxScroll(div)(-1)@00D5D26C < ScrollPortFrame(div)(-1)@00D5D314 < Area(div)(-1)@00D5D220 < line 00D5D45C: < Text(0)@00D5D5A0 < "a" > > > > > > > > The logic failed to test nsGfxFormControl2 et. al. to see if /they/ could stop the text run, so we'd mosey all the way down to the form control's text node and say, "yeah, that'll continue my happy text run." From there, all kinds of stuff would get out of whack. The fix is to test each frame as we descend down through the hierarchy to see if *any* of them are text run busters.
Keywords: regression, rtm
r=buster I think this is worthwhile for rtm, given the unpredictable results from the error and the moderate risk of the fix. It will need quite a bit of testing before it goes in the branch, though.
Requesting a triage on this bug. It's nominated but doesn't have a - or +. Are we going to fix this for rtm ?
karnaze, I got an a= from sfraser, could you float this for rtm+? It affects home.netscape.com, of all places...
Changing the url from email@example.com to home.netscape.com. Marking rtm+ because it is our home page.
RTM++. Please land on branch asap. Thanks, Jim
Whiteboard: [rtm+] → [rtm++]
*** Bug 46679 has been marked as a duplicate of this bug. ***
Fix checked in on branch and trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Fixed in the Oct 18th branch build.
Verified Fixed on trunk builds linux 101808 RedHat 6.2 win32 101804 NT 4 mac 101804 Mac OS9 Setting bug to Verified and removing vtrunk keyword
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.