263806 - XUL input fields (textfields) are too high

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[HARUNAGA Hirotoshi]

URL in Location bar (address bar) is slid up on Mac
This was introduced by the patch for Bug 167001 and probably Mac only.
regression.

Comment 1

[HARUNAGA Hirotoshi]

Attachment: Screenshot of current cvs build

Comment 2

[Simon Montagu :smontagu]

I see it on Windows as well.

Comment 3

[Frank Wein [:mcsmurf]]

Might it be that this also affects other XUL input fields (i see the same in
Chatzilla Input, MailNews password dialog, etc.)?

Comment 4

[Frank Wein [:mcsmurf]]

David: Can you back this patch out (i also tested it, this bug is caused by Bug
167001)? Or provide a solution for this bug here ;-)

Comment 5

[Bernd]

I am rising severity on this bug, it just horks the UI. 

This is the second major regression caused by the insufficient testing of the
patches in bug 167001. If Hideo can't ensure the proper working, then it needs
to be tested by someone else. But I believe it is the obligation of the patch
submitter to ensure proper working before asking for review, rather than
expecting that the reviewer will test it for the patch submitter. So if your
machine uses only asian fonts then you need to ask somebody with a latin setup
to test the patch before checkin. But fixing one bug at the expense of
regressions is not an option.

Comment 6

[Hideo Saito]

Sorry, this is my mistake and my error.
I can not see it on Japanese WindowsXP using both own build of released
mozilla-1.8a4 and latest build. 

Smontagu, please back it out.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The last patch in bug 167001 is the right thing to do, and if that changed the
alignment of stuff in XUL textboxes then something is seriously broken about XUL
textboxes.

Could somebody try changing the 'line-height: inherit ! important' in
chrome:://global/skin/textbox.css to 'line-height: normal ! important'?  The
previous patch made text inputs respect the 'line-height' property for the first
time (although it's set to normal ! important in ua.css), but if ua.css and
textbox.css are at the same cascade level then it could override (I'm not sure
if they are).

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It's worth noting that this bug only shows up for users who have really tiny fonts.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: any chance this helps?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, that's unlikely to work, but I really don't see what could have caused
this.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So, the only thing this patch could have changed is how tall the
nsTextControlFrame was.  Could somebody look in DOM inspector to see whether it
got shorter or taller with the patch?

Comment 12

[Bernd]

Attachment: textbox testcase

The testcase shows that the textbox does not get the font height information

Comment 13

[Bernd]

the patch as expected does not help :-(

The reflow log shows:

 root 03307558 r=2 a=7860,3480 c=7860,3480 cnt=1596
  place 03307DA4 r=2 a=7860,UC c=7860,0 cnt=1597
  place 03307DA4 d=0,0
  area 0331E524 r=2 a=7692,UC c=7692,240 cnt=1598
   text 0331E94C r=2 a=7692,UC c=UC,UC cnt=1599
   text 0331E94C d=10476,2148
  area 0331E524 d=10476,240 o=(0,0) 10476 x 2232
 root 03307558 d=7860,3480

the scrollable frame gets a computed height of 240 and then does not increase
but puts the text rather in the overflow area.

Comment 14

[Bernd]

What I see from my debugging is that the font height for the font metrics at
nsTextControlFrame::CalculateSizeStandard is 1920 while the font that is queried
in nsHTMLReflowState::CalcLineHeight has only a line height of 192. Further it
looks like that: 
const nsStyleFont* font = aStyleContext->GetStyleFont(); 
does not return cached style data but makes a new style computation. It returns
192 regardless what you set in the window style.

Comment 15

[Hideo Saito]

Attachment: patch

Comment 16

[Hideo Saito]

Attachment: patch

For the testcase, a frame of aReflowState is not right, it is nsRootBoxFrame.

Comment 17

[Frank Wein [:mcsmurf]]

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

Comment 18

[Bernd]

Comment on attachment 161871 [details] [diff] [review]
patch

This indeed fixes the bug. It also improves the situation in the testcase
compared to the phase prior to the checkin for bug 167001 where in the testcase
one could scroll a little bit the text.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2004-10-12 10:58 -0700.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I filed bug 264063 on the reflow state having the wrong frame.

Comment 21

[Bill Mason]

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

Comment 22

[Urgo]

Attachment: popup problem still

This image shows that the search engine and previous url popup box appears in
the wrong place still using the latest daily build.  This started happening
within the past week for me.  The fields themselves are now in the proper
location, its just the popup doesn't pop up in the right place.

Comment 23

[Urgo]

Attachment: another example of the popup problem

When clicking on the QA menu the window pops up right under the mouse.	The
same happens for every menu.

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 161978 [details]
popup problem still

This is a totally different bug.

Comment 25

[Urgo]

(In reply to comment #24)
> (From update of attachment 161978 [details])
> This is a totally different bug.
> 

Bug 264074: https://bugzilla.mozilla.org/show_bug.cgi?id=264074 was marked as a
duplicate of this bug and the two events started happening at the same time.  If
this was supposed to be published as a seperate bug sorry.

Comment 26

[Tobias Fischer]

(In reply to comment #25)

Urgo, the bug you mean is already filed as Bug 263992 when i am right.