276882 - Input event not fired by elements from initially collapsed boxes.

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Pawel Chmielowski]

Textbox don't fire input events when it is in initialy collapsed element. If
textbox is collapsed after some interval events ara generated correctly.

If box is hidden instead of collapsed everything works as expected.

Comment 1

[Pawel Chmielowski]

Attachment: Example XUL page which shows this behaviour.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Neil, any idea what's up here?

Comment 3

[[e-mail]]

The text control frame looks as if it makes some guesses as to when it's safe to
fire input events, it appears to look for a reflow or get pref size when the
reflow state includes first reflow. However that is not firing in this case.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Not a DOM issue, then.  Sounds like XUL is screwing up reflow somehow.... :(

Comment 5

[Jonah Bishop]

Two questions:

1. Should this bug be marked confirmed? I can see it in both 1.0 and 1.0.1 (and
others apparently can too).

2. Where do the uninitiated look in the source code to help track down this
problem? If I knew where to start looking, I might be able to help.

Just FYI, this bug is rather annoying for toolbar authors (myself included). If
a toolbar that uses a control with "oninput" starts out hidden, the "oninput"
event never gets fired. This should certainly be fixed, IMO.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Actually, looks like the immediate problem here is fixed by the fix for bug 282645.

The reflow problem probably still needs to be tracked down.... Probably putting
breakpoints in the Reflow() method of nsTextControlFrame and seeing what's going on.

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

it's fixed now.

Comment 9

[Kevin Brosnan]

No changes were made to the code base by this bug, worksforme.

Comment 10

[Jonah Bishop]

I still see this problem in 1.0.7. The example page fails just as it says it
does. I'm assuming the fix is in 1.5 (I haven't tried it there)?

Comment 11

[Zibi Braniecki [:zbraniecki][:gandalf]]

yes. It's fixed in 1.5

Comment 12

[Boris Zbarsky [:bzbarsky]]

Jonah, 1.0.7 is using code from April 2004 with security fixes only.

Comment 13

[Jonah Bishop]

I see. Sorry for the misunderstanding.