Text inputs intermittently appear strange

RESOLVED DUPLICATE of bug 5693

Status

()

Core
CSS Parsing and Computation
RESOLVED DUPLICATE of bug 5693
16 years ago
16 years ago

People

(Reporter: Warner Young, Assigned: dbaron)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Build 2001083103, Win98.  On the given URL (http://www.aberdeeninc.com), if you
type something into a text input, like the Search box, and then move the mouse
to the border, you'll sometimes see your input text underlined, like the
hyperlinks on the page.  However, moving the mouse directly over the text, it
looks fine.

I'm guessing this is a style system bug, but I'm not sure.
(Assignee)

Comment 1

16 years ago
Created attachment 48043 [details]
testcase
(Assignee)

Comment 2

16 years ago
The fact that it isn't always underlined is the weirdness that results from
non-hierarchical :hover (bug 5693).

Having a simple ":hover" selector style text inputs is correct, although it
surprises me that we allow it in quirks mode (where it doesn't style P elements,
for example).  Perhaps a ":hover" selector shouldn't apply to inputs in quirks
mode?  (I can't remember if we made that a quirk because of breaking pages or
for performance reasons.)
(Assignee)

Comment 3

16 years ago
Currently we do the following check whether or not we're in quirks mode to see
if we allow :hover, :active, or :focus to apply:


static PRBool PR_CALLBACK IsEventSensitive(nsIAtom *aPseudo, nsIAtom
*aContentTag, PRBool aSelectorIsGlobal)
{
  // if the selector is global, meaning it is not tied to a tag, then
  // we restrict the application of the event pseudo to the following tags
  if (aSelectorIsGlobal) {
    return PRBool ((nsHTMLAtoms::a == aContentTag)      ||
                   (nsHTMLAtoms::button == aContentTag) ||
                   (nsHTMLAtoms::img == aContentTag)    ||
                   (nsHTMLAtoms::input == aContentTag)  ||
                   (nsHTMLAtoms::li == aContentTag)     ||
                   (nsHTMLAtoms::label == aContentTag)  ||
                   (nsHTMLAtoms::select == aContentTag) ||
                   (nsHTMLAtoms::textarea == aContentTag) ||
                   (nsHTMLAtoms::textPseudo == aContentTag) ||
                   // We require a Layout Atom too
                   (nsLayoutAtoms::textTagName == aContentTag)
                  );
  } else {
    // selector is not global, so apply the event pseudo to everything except
HTML and BODY
    return PRBool ((nsHTMLAtoms::html != aContentTag) &&
                   (nsHTMLAtoms::body != aContentTag));
  }
}

Comment 4

16 years ago
We used to do that check only in Quirks mode, but that was changed for
performance reasons (I think there was a W3C page that was strict and had :hover
or something and we took extreme amounts of time to scroll and mouse around).
(Assignee)

Comment 5

16 years ago
I guess my opinion is that there's nothing to fix here beyond bug 5693.  Please
comment or reopen if you disagree.

*** This bug has been marked as a duplicate of 5693 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.