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

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

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.

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

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 :)

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.

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

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.

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.

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 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 ?

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 back?...

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

+ + baby...

nsbeta3+, P3 for M18, cc jrgm

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.

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

Reassigning to saari to fix the event.target

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

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

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.

Fixed

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

Updating QA Contact.

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

QA contact updated

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