536172 - Textbox caret doesn't display with a specific combination of Markup, CSS and JS

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Eirikur H. Nilsson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6

Had an issue in a big webapp where carets in textboxes would disappear after validation. This happens in all versions after FF 3.0 (haven't tried earlier)

It happened when using clearfix on an inline wrapper that contained a floated textbox and some other content, but only after using some javascript to mess with the DOM.

After a lot of work I managed to reproduce it in a relatively simple testcase. There are a lot of random condition for this bug to happen, and maybe some of it is bad practice on my part, but it's still a very annoying bug that is pretty hard to figure out.

Reproducible: Always

Steps to Reproduce:
1. Run the provided testcase and give the textbox focus.

OR to create a testcase yourself:
1. Put a textbox and a block element inside a inline wrapper.
2. Apply a :after style that appends some content on the wrapper.
3. Use JS to create an empty div and add to the body
4. Add a onhover event handler to the textbox that touches the wrapper (f.ex. adding/removing css classes) and use jquery.is(':hidden') on the div in step 3.
5. Run the test and give the textbox focus.
Actual Results:  
No caret is displayed, the textbox is still editable but no indicator of caret position is available.

Expected Results:  
Caret should be displayed

Comment 1

[Eirikur H. Nilsson]

Attachment: A reproduction of the bug.

This testcase reproduces the bug. It can be observed in any version after Firefox 3.0

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7pre) Gecko/20091220 Shiretoko/3.5.7pre

I can indeed reproduce this bug with Firefox 3.5, but it is fixed in the latest trunk nightly build.
Resolving WFM.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  As far as I can see, on Mac, this got fixed between the 2009-12-10-03 nightly (rev e41f3b73ee3e) and the 2009-12-11-03 nightly (rev 9af2a428dcb1).

Pushlog range:  http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e41f3b73ee3e&tochange=9af2a428dcb1

Ria, is that also the range you see?  Nothing in that range jumps out at me as a likely patch to have fixed this, except maybe bug 528829.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Weird.  This seems to have gotten fixed by bug 523294 part 2 if my local bisect isn't lying to me...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Confirmed comment 4 on both Mac and Linux.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK.  So looking at the testcase, it looks like the key parts are:

1)  An {ib} split
2)  :after style on the containing inline.
3)  Setting and removing a class that does absolutely nothing on the containing
    inline inside the focus handler.
4)  A style (or maybe layout, who knows what the heck jquery is doing in that
    is() call) after the class set/remove and inside the focus handler.

Bug 523294 made it so that item 3 does NOT trigger a style reresolve on the <span>.  When the style reresolve was triggered, I bet the combination of item 1 and item 2 caused us to always reframe the span.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase showing the problem in a tip build, no jquery needed

Comment 8

[Boris Zbarsky [:bzbarsky]]

Reopening.  There are two issues here:

1)  :after detection in an {ib} split is busted, leading to a spurious reframe.
    Filed bug 536419.
2)  Reframing a text input during onfocus loses the caret.  Filed bug 536421.

Comment 9

[Alice0775 White]

I cannot reproduce the problem any more

https://hg.mozilla.org/releases/mozilla-beta/rev/790546ceb89f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20150319212106