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

NEW
Unassigned

Status

()

Core
Layout: Form Controls
8 years ago
3 years ago

People

(Reporter: Eirikur H. Nilsson, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

8 years ago
Created attachment 418634 [details]
A reproduction of the bug. 

This testcase reproduces the bug. It can be observed in any version after Firefox 3.0
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Version: unspecified → 1.9.1 Branch
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.
Weird.  This seems to have gotten fixed by bug 523294 part 2 if my local bisect isn't lying to me...
Confirmed comment 4 on both Mac and Linux.
Depends on: 523294
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.
Created attachment 418872 [details]
Testcase showing the problem in a tip build, no jquery needed
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.
Status: RESOLVED → UNCONFIRMED
Depends on: 536421, 536419
OS: Windows 7 → All
Hardware: x86_64 → All
Resolution: WORKSFORME → ---
Version: 1.9.1 Branch → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 9

3 years ago
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
You need to log in before you can comment on or make changes to this bug.