46505 - event.target for inputs is wrong.

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Matthias Kerkhoff]

From Bugzilla Helper:
User-Agent: Mozilla/4.74 [en] (WinNT; U)
BuildID:    2000072408

Text entered in absolute positioned input elements is always displayed at 
x=0,y=0

Reproducible: Always
Steps to Reproduce:
1. Load the url mentioned above
2. Click into the "User-Name" or "Password" field at the bottom of the page
3. Enter some text

Actual Results:  You will see the text you've entered in the upper left corner 
of the frame.			

Expected Results:  The text should be displayed in the control.							

Also happens with the builds from 25.7

Comment 1

[Hixie (not reading bugmail)]

I'm having difficulty going to that site right now.

Comment 2

[Kevin McCluskey (gone)]

It displays HTML in all of the frames in the frameset on both Mozilla (Current 
build) + 4.x.

It displays correctly in I.E 5.

Comment 3

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 4

[Hixie (not reading bugmail)]

The server is returning the frames as text/plain, so we are not buggy in
displaying the source.

Reporter: Could you attach a small version of the offending page (the one with
the absolute positioning bug) to this bug, so that we can examine it? Thanks.

Comment 5

[Matthias Kerkhoff]

Ok, I found it. I don't submit a testcase because it has an easy explanation.
On the page with the misbehaving edit control I have using a style declaration
similar to this one ...

BODY DIV {position:absolute; left:0px top:0px;}

Due to the fact that the edit control is implemented with an undocumented child 
DIV, my rule also matched the controls DIV and positioned it to the top left. 
It's easy to workaround for me, but I think this behaviour (undocumented childs 
of controls) is one that definetly should be documented somewhere. I recall that 
I have read about it in some other bug report some days ago. Just didn't make 
the connection between the fact and my problem. 

Could someone else please judge how to continue with this bug - changing subject 
and type, closing or whatever. Thanks.

PS.: From my point of view this is a bug. A web designer never _should_ have to 
know how standard html elements are composed. In the current situation, my 
example shows that this undocumented knowledge is necessary sometimes.

PPS.: I changed my mind and will attach a testcase. Just in case someone needs a 
demonstration :)

Comment 6

[Matthias Kerkhoff]

Attachment: testcase

Comment 7

[Matthias Kerkhoff]

Also happens with build from 27.7

Comment 8

[Hixie (not reading bugmail)]

Great work tracking that down!

The solution for this problem -- and this IS a problem and no messing :-) --
is to move this 'DIV' into a different namespace and then make that namespace
one of the 'hidden' ones that nothing matches unless it is explicitly selected.

This is therefore dependent on bug 21890. Marking dependencies.

Comment 9

[rods (gone)]

It appears that the anonymous content is being acess? maybe?

reassigning

Comment 10

[Marc Attinasi]

Beth asked me to look at this, and I am in full agreement with Matthias that the 
problem is with the descendent selector taking into account anonymous content - 
it definitely should not. From (#tb-logged-off DIV to #tb-logged-off > DIV) then 
it works fine. I think that there is an existing bug on anonymous content being 
used in selector matching - I'll go and look now. Also, I'll take this over 
since it is a style problem.

Comment 11

[Marc Attinasi]

Ian, don't you think that selector matching should ignore anonymous content 
completly, regardless of the namespace it is in?

Comment 12

[Pierre Saslawsky]

We can't ignore anonymous content, or at least not regardless of the namespace, 
otherwise we'll break XML.

Comment 13

[Hixie (not reading bugmail)]

I thought I'd commented, but it seems I did not. Hmm!

I don't see what anonymous content has got to do with this. The problem is that
as I understand it the content tree is going:

   |
   +-- INPUT
   |    +-- DIV
   |
   +-- ...

Where is the "anonymous" content? The problem is that to the stylesystem, the
DIV that we generate inside the INPUT is being matches by a *|HTML selector,
which it should not (per our discussion during the triage meeting).

So the solution to _this_ bug is just to put the DIV element in the Zool, er,
XUL, namespace, and when Pierre fixes bug 21890 by making *| not match the XUL
namespace, this bug automatically be fixed.

Comment 14

[Marc Attinasi]

Ian, in your example the DIV is the anonymous content: we create it for the 
internal implementation of the INPUT, but it cannot be accessed via the DOM. I 
am learning now that we actually _do_ have to style anonymous content, that is 
how we handle CSS generated-content, and in fact that is what anonymous content 
was initially designed for (so I've been told)!

So, back to the namespace problem. Talking to Kevin McClusky, he remarked that 
originally the design required anonymous content created for the purposes of 
internal implementation to be given alternate names, like MZO_INNER_SCROLL for 
the DIV in an INPUT control, for example. However, that is not what happened: 
instead people either just create the anonymous content (like the DIV in the 
INPUT) or use pseudo-styles to get styling on internal parts of their elements. 

Now that I understand more of what it means to have anonymous content, 
spceifically why it must be styled, I believe that we really have to find each 
case of anonymous content creation and make sure it is namespaced correctly. In 
this case, it is INPUT so this needs to the INPUT element onwer - Rod S.?

Comment 15

[Hixie (not reading bugmail)]

Marc: Sorry, I misunderstood the term "anonymous content". In CSS, anonymous
content is that which has no associated element. Since the DIV had an associated
element -- a DIV -- I'd assumed it was not anonymous. All is clear now. ;-)

Comment 16

[Marc Attinasi]

Approving for nsbeta3: there are many ares that need to be fixed to get this all 
working correctly, so dependencies may need to be created.

Comment 17

[Matthias Kerkhoff]

I've just discovered an interesting side-effect of this bug:
Whenever I register a mouseover handler for an INPUT[type=text|password] and 
move the mouse over the control, the eventTarget in the handler will point to 
the anonymous DIV and _not_ to the INPUT control. Should I file a separate bug 
(and/or a testcase) on this ?

Comment 18

[Matthias Kerkhoff]

Let me answer my previous question ... yes - I think there is a related problem, 
described in my previous comment. 
I've played a bit more with the mentioned handler and found out, that the 
event.target in mouseover is set a DIV. The DIVs parentNode is the INPUT 
element. But.... 
... if I 'ask' the INPUT element for it's first child (well, it should have at 
least one - the DIV) it tells me: No, don't know what you're talking about, I 
don't have any children (i.e. the INPUT's .firstChild DOM-property does not 
exist _but_ the DIV's parentNode points to the INPUT).

This is inconsistent - I should have either _no_ access at all to the DIV 
(shouldn't know anything about it) _or_ it should not matter how I traverse the 
DOM tree ('top.down' or 'bottom.up').

Could someone please CC: this to the DOM team ?

Comment 19

[Marc Attinasi]

I believe that it is a separate bug that the eventTarget for your handler is the
DIV. The internal DIV is anonymous content and should not be visible /
accessable to the author's script.

JST or RodS, any idea why this is happening? I know we use a DIV internally, but
shouldn't the target for the handler be the INPUT?

Comment 20

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

I think the way ender-lite currently works that might be difficult.  I *think*
the reason it works for other form controls is that they trap events using
GetFrameForPoint hacks.

Comment 21

[Johnny Stenback (:jst)]

CCing David Hyatt cause I think he has some ideas on how to fix this a while
back?...

Comment 22

[Hixie (not reading bugmail)]

Hyatt claims (!) that his Walling Off Anonymous Content solution would allow
this to be fixed by converting the hardcoded Ender DIV into an XBL version.

Thus, reassigning to Hyatt. (He volunteered for this.) Marc: I hope you don't
mind me reassigning your bugs to other people. If you run out of nsbeta3+
bugs, just give me a shout, ok? I have a long list of other bugs that need
fixing, which we nsbeta3-'ed... ;-)

Comment 23

[David Hyatt]

Note that converting the DIV to XBL will enable me to fix the styling problem
and the event targeting problem.

Comment 24

[Marc Attinasi]

Ian: no problem, actually, thanks ;)
David: you rock, bro!

Comment 25

[Peter Trudelle]

renominating for triage by current owners

Comment 26

[David Hyatt]

+ + baby...

Comment 27

[Peter Trudelle]

nsbeta3+, P3 for M18, cc jrgm

Comment 28

[David Hyatt]

I have fixed the style problem.  A separate bug should be opened against joki or 
saari for the event.target being wrong.  I was unable to use XBL like I'd hoped. 
 It ended up being too problematic.  This means event.target will have to be 
hacked separately for the input field.

Comment 29

[Pierre Saslawsky]

Reopening and reassigning to saari to fix the event.target.

Comment 30

[Pierre Saslawsky]

Reassigning to saari to fix the event.target

Comment 31

[saari (gone)]

Uh, I thought event.target was already hacked? Hyatt can you verify that?

Comment 32

[David Hyatt]

No, it was hacked for <input type=file>, but not for <input type=text>.

Comment 33

[saari (gone)]

Note to self; need to use GetRealTarget in ender as they're listening off the
htmlInput element, not the div. That should work already, then hack the input to
retarget the event ala input type=file.

Comment 34

[saari (gone)]

Fixed

Comment 35

[Hixie (not reading bugmail)]

Sorry Jan, I don't know how to test "event.target". :-(

Comment 36

[Loco]

Updating QA Contact.

Comment 37

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 38

[Madhur Bhatia]

QA contact updated

Comment 39

[luis rincon]

verified in build 2001-07-13-07-trunk