From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 BuildID: 2002053012 When loading a web page in the browser, if the mouse happens to lie on top of a just-rendered link, that link's "hover" pseudo-style won't be in effect. Subsequently moving the mouse a tiny bit will cause the hover style to take effect. The URL above is a simple test case that demonstrates this. Reproducible: Always Steps to Reproduce: 1. Follow a link to a page, where the mouse is positioned such that it will be on top of a link on the destination page Actual Results: The link's style was left at its default. Expected Results: The link's :hover pseudo-style should be in effect.
WFM in the June 12th Windows ME build (2002-0612-05 1.0.0)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Interesting -- does bug 20022 or bug 112829 also work for you? I suspect 112829 is another symptom of the same problem.
Reproduced with trunk build 2002061108 on Win2k. Reopening. I can't reproduce bug 112829 anymore, though. firstname.lastname@example.org, can you reproduce bug 112829?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Are you sure you're not seeing the bug that :hover state goes away when you press a key and stays that way until you move the mouse again?
dbaron: I'm seeing both.
I cannot reproduce 112829. So maybe they're not related. However, in 112829's test case, if I position the mouse somewhere where a link *could* be, and scroll the scrollbar until a link appears under the mouse, the :hover state is not in effect until the mouse is moved. That may be an unrelated but similar issue though.
> I cannot reproduce 112829. So maybe they're not related. Bug 112829 seems to have gone away. > However, in 112829's test case, if I position the mouse somewhere > where a link *could* be, and scroll the scrollbar until a link > appears under the mouse, the :hover state is not in effect until > the mouse is moved. That may be an unrelated but similar issue > though. I believe that issue is the same as this bug. This bug is the same as bug 20022 except that this is about content while 20022 is about chrome. Unable to find a dupe; confirming and reassigning to event handling.
Assignee: attinasi → joki
Component: Layout → Event Handling
QA Contact: petersen → rakeshmishra
(I could have sworn I had checked that Confirm checkbox...)
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 154923 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 46388 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.