Closed Bug 280708 Opened 15 years ago Closed 15 years ago

[FIX]hang/freeze when hovering over input (using input:hover,td:hover {display:table-row-group}


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






(Reporter: martijn.martijn, Assigned: bzbarsky)


(Keywords: regression, testcase)


(2 files)

See upcoming testcase. 
Current trunk builds hang/freeze when hovering over the <input> in the testcase.
This happens because I Used 
as css rules.
Attached file Testcase
Keywords: testcase
Martijn, as usual bugs like this need to get prioritized. The main criteria for
me is regression. Can you try this with FF 1.0 (class:somehow old, should be
fixed for 1.1) and even Seamonkey 1.6 (class: ancient, we need to fix this but
1.1 is not a milestone)
Ah, ok. I'm testing (semi-)randomly, that's why I wasn't testing it in older
builds, but I'll do that from now on.

It doesn't freeze/hang with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050124 Firefox/1.0+
But it does freeze hang with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050125 Firefox/1.0+

Maybe a regression from fixing bug 269566?
Keywords: regression
Yeah, probably... I'll look into this one.
Attached patch PatchSplinter Review
This is effectively the same as the patch for bug 275746 (and backs that patch
out, really), but I've pushed the code down into CreateAnonymousFrames, since
all callers of the method would need to do this....  In particular, <input>
creates anonymous frames for the editor inside it, so needs this.
Assignee: nobody → bzbarsky
Attachment #173187 - Flags: superreview?(roc)
Attachment #173187 - Flags: review?(bernd_mozilla)
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Summary: hang/freeze when hovering over input (using input:hover,td:hover {display:table-row-group} → [FIX]hang/freeze when hovering over input (using input:hover,td:hover {display:table-row-group}
Target Milestone: --- → mozilla1.8beta
Attachment #173187 - Flags: superreview?(roc) → superreview+
Boris, is this really correct given the fact that even ConstructTableFrame calls
I think it's correct, yes.  Note that the very first line in
CreateAnonymousFrames (the version that ConstructTableFrame calls, not the one I
changed; the latter is called by the former) bails out if the node is not a root
(which is a table never claims to be) and if the tagname isn't in a specific list.

Also note that I'm only doing this pseudo thing if the tag is one we want to
craete anonymous content for (so the inner method got called) _and_ the parent
frame QIs to nsIAnonymousContentCreator (which table frames do not) _and_ it
creates anonymous content.

This isn't the "totally right" fix, since anonymous content with table display
types should really share pseudo-frames with non-anonymous kids with table
display types.  But that's something that would be easier to fix with a general
pseudo-frames revamp...
Attachment #173187 - Flags: review?(bernd_mozilla) → review+
Just for reference, the parts of the diff that deal with iterators and
ProcessAttachedQueue were not supposed to be there... I'll remove them before
checking in.
Closed: 15 years ago
Resolution: --- → FIXED
Upon hovering over the test case, the text box moves off to the right. Is this
expected behaviour?
Ger, that's a known bug (don't know the bug number), but unrelated to this bug.
When this bug is fixed (which it should in 20050204 trunk build), it should
indeed show that behavior you described (and not hang/freeze).
Verified using 20050204 trunk build.
Checked in a crashtest and reftest for this.
Flags: in-testsuite+
The reftest 280708-1a.html actually failed on all Tinderbox platforms, so I marked it as expected-fail and filed bug 473824 for it.
You need to log in before you can comment on or make changes to this bug.