18445 - Text input confused by floating element [FLOAT]

Status: VERIFIED FIXED

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

Description

[Hixie (not reading bugmail)]

An <input> element that is given 'display:block' is not acting as it should
according to the CSS specs.

See http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/widgets/11.html
for some simple test cases. For example, if an input that is styled as
"display:block" is preceeded by a float, the input element will not go under
the float as it should.

Comment 1

[karnaze (gone)]

Reassigning to Kevin.

Comment 2

[Kevin McCluskey (gone)]

This may be a duplicate of the problem of placing input elements which are area
frames.

Comment 3

[rods (gone)]

I think this is because of the embedded webshell has its own window. Should work
fine once we move to a lightweight webshell. reassigning to steve.

Comment 4

[buster]

probably a dup of 16272.  Marked M20 which means we'll look at it after beta 1
entry. 16272 is marked M13, so this might get addressed much sooner if it really
is just a duplicate.

Comment 5

[Hixie (not reading bugmail)]

Note that the bugs visible here are not so much that the input goes over the
float, as it does due to bug 16272, but that they are incorrectly positioned.

For example, in the second test on the page, the input control is centered
in the space left due to the float rather than the space of the containing
block. It should be centered just like when there is no float at all (as in
the first test).

I'm going to increase the severity which I had set to "minor" up to "normal"
since this is really a standards-compliance issue.

Comment 6

[gerardok]

QA Contact update.

Comment 7

[Hixie (not reading bugmail)]

This bug is basically the same as bug 23412, but I am not marking this as a DUP
since this bug uses form fields and bug 23412 uses images.

Comment 8

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 9

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 10

[buster]

This bug is marked "future" because it is not critical for RTM (Release To 
Manufacturing). If anyone believes it is critical, please explain why
in this bug. 

Comment 11

[Hixie (not reading bugmail)]

One reason not to move this to Future is that it is a serious CSS1 standards 
compliance error. Cc'ing Eric Krock for standards compliance judgement call.
Cc'ing David in case he hasn't come across this floater bug before.

Comment 12

[ekrock's old account (dead)]

Ian, could you explain for us the practical impact on content designers if this 
bug is not fixed? Is there a workaround? What effect becomes impossible? What 
features of the standards (if any) are left unusable for the future because of 
this? Starting now, we need to do this for all standards compliance bugs in 
order to assess relative severity vs. other standards compliance bugs as well as 
other bugs unrelated to compliance. Thanks for your help!

Comment 13

[Hixie (not reading bugmail)]

The main problem with this is that if we don't fix it, then when we _do_ fix it,
any pages relying on our current broken behaviour will end up having text fields
and images overlapping.

For example, go to the test page:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/widgets/11.html
...and look at the bottom test. At the moment, the input sits next to the float.
This is actually incorrect -- and once we correct it, anyone who is depending
on this behaviour will end up having the input and the green box overlapping.

Hence, I would say that this destroys this feature of CSS1. (Floating block
level elements that happen to be widgets.)

Comment 14

[Hixie (not reading bugmail)]

Based on my last comment, removing Future milestone.

Comment 15

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

Has this changed at all since Ender-lite landed?  I wouldn't think so, but 
there's a chance...

Comment 16

[Hixie (not reading bugmail)]

No, we are still buggy in Win32 2000061520.

Comment 17

[Hixie (not reading bugmail)]

As per meeting with ChrisD today, taking QA.

Comment 18

[ekrock's old account (dead)]

correctness. Whenever the engineering resources exist, we do want to avoid
creating future issues where if we fix a compatibility bug in a future release,
we break content written to the first release.

Ian -- Would there be any way that a developer could code in a correct way
(maybe with some add'l settings) so that they'd get the same result both on an
initial release *with* this bug and a later release without it?

Comment 19

[Hixie (not reading bugmail)]

Ummm...... I can't think of any, no.

The bigger problem is not that authors cannot get the correct result, though,
but that authors are likely to get the current, buggy rendering, think it's 
good, and design their sites with it this way... then when we fix it, boom go 
their text inputs, sliding under the images.

This isn't exactly likely to become a top100-type problem, but with our
improved standards support it is likely to happen enough for us to end up 
having to deal with a b.c. issue in the next release.

Comment 20

[Marc Attinasi]

Taking a stab at prioritizing buster's nsbeta3 bugs...

Comment 21

[buster]

I'm on this.

Comment 22

[leger]

If buster can get it done..awesome, but PDT is downgrading to a P3.  Would not 
hold if time got short. Putting on [PDTP3]

Comment 23

[buster]

The problem is in nsBlockReflowState::ComputeBlockAvailSpace()
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsBlockFrame.cpp#76
8
This method computes the amount of space available to a block that is about to 
be reflowed.  In the case of a block frame, aSplitType will be 
NS_FRAME_SPLITTABLE_NON_RECTANGULAR, and we take floaters into account.  In the 
case of a text control mapped to display:block, aSplitType will be 
NS_FRAME_NOT_SPLITTABLE, and we blindly return the previously computed 
mAvailSpaceRect.width.
I don't have a clue why we do different computations based on whether the frame 
is splittable or not.  Researching....

Comment 24

[buster]

I've got a potential fix for this.  Testing now...
I could really use a very detailed, focused test case for this sort of thing.
I'm running through all the test suites I know, and writing some of my own.  But
if I could get some help with more detailed test cases, that would be great.

Comment 25

[buster]

I've got a potential fix for this.  Testing now...
I could really use a very detailed, focused test case for this sort of thing.
I'm running through all the test suites I know, and writing some of my own.  But
if I could get some help with more detailed test cases, that would be great.

Comment 26

[Hixie (not reading bugmail)]

Test cases:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/widgets/11.html
   http://bugzilla.mozilla.org/showattachment.cgi?attach_id=4065

Buster: If you want more tests, mail me or call me (MV, x6593) and I'll build
whatever you need.

Comment 27

[buster]

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

Comment 28

[buster]

Attachment: test case from dup bug 23412

Comment 29

[buster]

fixed, checked in 9/14/00

Comment 30

[Hixie (not reading bugmail)]

Attachment: Alternative version of previous testcase (strict mode; valid)

Comment 31

[Hixie (not reading bugmail)]

VERIFIED FIXED using Windows 2000 and Linux Commercial builds 200009180[56].