233094 - [FIXr]input text doesn't appear in text box if text box is in floated cell

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P2)

Description

[james.d.baker]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

I have a page with a search (input) box in a table cell. This cell has a
background image which is set via CSS. When I click in the text box, the cursor
doesn't show up. I tried typing and I found that the text appeared to the left
over the top of a different cell.

Note: The URL may be taken down soon.

Reproducible: Always
Steps to Reproduce:
1. Goto page
2. Click in search box and type
3. Text appears up and to the left

Actual Results:  
The text appeared in the wrong place, and over the top of everything else

Expected Results:  
The text should have appeared in the input box

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimal testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

roc, would misparented views cause this?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

sure could.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Eviler testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Even eviler testcase

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: This fixes all three testcases and the website

The basic idea is that when we construct the pseudo cell we need to make it the
float containing block....

This is a little fragile, though -- there may be other codepaths that could
produce pseudo cells.  It really would be better if we could keep track of this
in the frame constructor state somehow... perhaps mPseudoFrames could push the
floater block when it creates the anonymous table cell and pop it when
ProcessPseudoFrames is called or something?  But that can introduce nesting
issues with other pushes....

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 140654 [details] [diff] [review]
This fixes all three testcases and the website

David, what do you think?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

you rock

Comment 9

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

Comment on attachment 140654 [details] [diff] [review]
This fixes all three testcases and the website

I'm not crazy about any of the table pseudo frame construction code, and I
don't remember my previous objection to this patch, but r+sr=dbaron.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> I'm not crazy about any of the table pseudo frame construction code

I'm not either.... I have some ideas on nuking all of it and replacing it with
something sane, but they're not to the point where I can coherently describe
them yet...

Comment 11

[Boris Zbarsky [:bzbarsky]]

Checked in for 1.8a trunk.

Comment 12

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

It might be worth requesting 1.7 approval for this.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 140654 [details] [diff] [review]
This fixes all three testcases and the website

Hmm.. yeah, this fixes issues with all sorts of sites, and should be reasonably
safe.  I've been running with this patch for a while now, with no ill effects
that I have seen.

Comment 14

[chris hofmann]

Comment on attachment 140654 [details] [diff] [review]
This fixes all three testcases and the website

a=chofmann 1.7

Comment 15

[Boris Zbarsky [:bzbarsky]]

Checked in on the branch.

Comment 16

[José Jeria]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

Note: this caused crash bug 263846.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Checked in some reftests for this.