Closed Bug 46505 Opened 23 years ago Closed 23 years ago for inputs is wrong.


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






(Reporter: make, Assigned: saari)



(Keywords: css1, testcase, Whiteboard: [nsbeta3+][nsbeta2-])


(1 file)

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

Text entered in absolute positioned input elements is always displayed at 

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
Keywords: css1, nsbeta2
I'm having difficulty going to that site right now.
QA Contact: ckritzer → py8ieh=bugzilla
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.
Target Milestone: --- → M22
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [nsbeta2-]
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.
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 :)
Keywords: testcase
Attached file testcase
Summary: absolute positioned input elements display text at (0,0) → DIV selector may also match undocumented child of INPUT element
Also happens with build from 27.7
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.
Keywords: 4xp, correctness, nsbeta3
Summary: DIV selector may also match undocumented child of INPUT element → children of INPUT etc... should not be in HTML namespace
Depends on: 21890
It appears that the anonymous content is being acess? maybe?

Assignee: rods → beppe
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.
Assignee: beppe → attinasi
Ian, don't you think that selector matching should ignore anonymous content 
completly, regardless of the namespace it is in?
We can't ignore anonymous content, or at least not regardless of the namespace, 
otherwise we'll break XML.
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.
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.?
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. ;-)
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.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
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 ?
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 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 ?
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?
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.
CCing David Hyatt cause I think he has some ideas on how to fix this a while
Assignee: attinasi → hyatt
OS: Windows NT → All
Hardware: PC → All
Target Milestone: M22 → M18
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... ;-)
Note that converting the DIV to XBL will enable me to fix the styling problem
and the event targeting problem.
Ian: no problem, actually, thanks ;)
David: you rock, bro!
renominating for triage by current owners
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-]
+ + baby...
Whiteboard: [nsbeta2-] → [nsbeta3+][nsbeta2-]
nsbeta3+, P3 for M18, cc jrgm
I have fixed the style problem.  A separate bug should be opened against joki or 
saari for the being wrong.  I was unable to use XBL like I'd hoped. 
 It ended up being too problematic.  This means will have to be 
hacked separately for the input field.
Closed: 23 years ago
Resolution: --- → FIXED
Reopening and reassigning to saari to fix the
Component: HTML Form Controls → Event Handling
Resolution: FIXED → ---
Reassigning to saari to fix the
Assignee: hyatt → saari
Uh, I thought was already hacked? Hyatt can you verify that?
No, it was hacked for <input type=file>, but not for <input type=text>.
Summary: children of INPUT etc... should not be in HTML namespace → for inputs is wrong.
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.
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Sorry Jan, I don't know how to test "". :-(
QA Contact: py8ieh=bugzilla → janc
Updating QA Contact.
QA Contact: janc → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
verified in build 2001-07-13-07-trunk
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.