25580 - [FIX][CSS][NavQ]padding and border resizes Input Text and Textarea incorrectly

Status: VERIFIED WONTFIX

(Core :: Layout: Form Controls, defect, P3)

Description

[jmraker]

Using M13 Win32 build.

Actual Results
The text field's border and padding is overlapping (rendered inside) the field 
itself.

Expected Results
The border and padding should appear outside of the field.

Comment 1

[jmraker]

Attachment: testcase.

Comment 2

[karnaze (gone)]

Reassigning to Rod.

Comment 3

[rods (gone)]

No, this is (strangely enough) the correct behavior for NavQuirks. The idea when 
laying out in NavQuirks is to be the same size as Nav. 

Nav does not handle this type of style, so we don't either for NavQuirks. If you 
then say, that we should never allow the border size to be greater than two 
so it would at least render nicely (and look like NavQuirks), then that is a 
reasonable request and maybe I could get it in for M15 or M16

It works correctly and as expected when in Standard mode.

Comment 4

[jmraker]

I was expecting everything to be the correct size.  The border and the widget
not overlapping like it is.  I'm not sure of the navquirks mode details and it's
limitations, but it would be nice to be able to use CSS properties on widgets
and have them work even if they are ugly.  Never allowing the border to be
increasd isn't the long term solution I hoped for, but neither is what it is
doing now in the test case.  If limiting the properties is the only way, it
would be better.

Comment 5

[jmraker]

Rereading the comment, it seems you are referring to compatibility with
Navigator of 4.xx and it's CSS abilites (what little it has).

I was under the impression that mozilla would be 100% CSS1 compliant.

Comment 6

[rods (gone)]

Mozilla in "Standard" should be fully standards compliant, if not file a bug. 
When it is in NavQuirks mode, it does what little (or maybe a little more) than 
what Nav 4.x does.

Switch the flafg in viewer or make sure your DTD is "Strict' and it will do the 
right thing.

Comment 7

[rods (gone)]

setting to M16 and marking low priority

Comment 8

[rods (gone)]

mass-move to M16

Comment 9

[rickg]

Moving out by executive order.

Comment 10

[rods (gone)]

This is because the NavQuirks sizing assume zero padding and a two pixel border. 
When we have a NavQuirks style sheet we can make the padding and border 
!important and solve this.

Comment 11

[Marc Attinasi]

nominating as nsbeta2 since the fix is a simple change to html.css now that the 
NavQuirk style sheet exists.

Comment 12

[Jim Roskind]

Can we see just how trivial this patch would be?  We have lots of bugs, and 
can't afford regressions just now (running towards beta2).

Comment 13

[leger]

Putting on [nsbeta2-] radar. 

Comment 14

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 15

[rods (gone)]

setting to M17

Comment 16

[Kevin McCluskey (gone)]

Marking nsbeta3+

Comment 17

[rods (gone)]

This was fixed when the quirk.css was put in a while back. marking works for me.

Comment 18

[rods (gone)]

Oops, that embarressing, it works for me because the change is in my tree. 
Reopening and and I will check the fix in today and then mark it fixed.

Comment 19

[rods (gone)]

fixed

Comment 20

[ckritzer (gone)]

Marking VERIFIED FIXED on:
- LinuxRH62 2000-09-07-08-M18 Commercial
- Win98     2000-09-07-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial

Comment 21

[rods (gone)]

reopening because I am removing the fix.

Comment 22

[rods (gone)]

marking won't fix.

Comment 23

[Boris Zbarsky [:bzbarsky]]

See bug 55336 for the fix removal

Comment 24

[ckritzer (gone)]

Correct QA Contact -> vladimire

Comment 25

[Vladimir Ermakov]

I'm verifying wontfix, although I dont see the problem....