Closed Bug 622246 Opened 13 years ago Closed 13 years ago

Drop down menu href links dont work when clicked


(Core :: DOM: UI Events & Focus Handling, defect, P1)




Tracking Status
blocking2.0 --- betaN+


(Reporter: thegooddale, Assigned: bzbarsky)




(Keywords: regression)


(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101230 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101230 Firefox/4.0b9pre

When you click on the "Sign In To..." on the right, a drop down menu appears. Clicking on any of the links should take you to a new page, but the browser does nothing after the onlick is done.

Reproducible: Always

Steps to Reproduce:
1. Go to
2. Click on the "Sign In To..." drop down menu.
3. Click on any of the links presented in the drop down menu.
Actual Results:  
The browser does not go to the new url page.

Expected Results:  
The browser should go to the new url page after clicking on a menu drop down link.

I don't think it is related to this bug: as I have disabled adblock plus and I am still encountering the error.

Also, I can't reproduce
Regression window:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101222
Firefox/4.0b9pre ID:20101227122945
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101223
Firefox/4.0b9pre ID:20101227124535
Blocks: 331959
Component: General → Event Handling
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → events
Version: unspecified → Trunk
blocking2.0: --- → ?
OS: Mac OS X → All
Attached file semi-reduced html
Attached file reduced html
Attached file Actually reduced
So what happens is that the targetContent returned by GetEventTargetContent on the ESM is the textnode inside the <a> (because that's the ESM's mCurrentTargetContent), not the <a> itself.

If I don't remove things from the DOM, then the ESM's mCurrentTargetContent is null, and we ask the presshell, which sees that its mCurrentEventContent is the <a> and returns that.
Ah, and that's because ESM sets mCurrentTargetContent from ClearFrameRefs... and then doesn't do anything interesting if there's event dispatch nested inside the handling of the other event.  smaug, is there a reason to actually use GetEventTargetContent here?  I stole that code from CheckHandleEventForAnchorsPreconditions, but perhaps I really don't want that here.
Attached patch Proposed fixSplinter Review
Attachment #500549 - Flags: review?(Olli.Pettay)
Assignee: nobody → bzbarsky
Priority: -- → P1
Whiteboard: [need review]
blocking2.0: ? → beta9+
Comment on attachment 500549 [details] [diff] [review]
Proposed fix

>   case NS_UI_ACTIVATE:
>     {
>-      nsCOMPtr<nsIContent> targetContent;
>-      aVisitor.mPresContext->EventStateManager()->
>-        GetEventTargetContent(aVisitor.mEvent, getter_AddRefs(targetContent));
>-      if (targetContent == this) {
>+      if (aVisitor.mEvent->target == this) {

Could you use ->originalTarget here?
Attachment #500549 - Flags: review?(Olli.Pettay) → review+
Yeah, I think I could.  I'll do that.
Whiteboard: [need review] → [need landing]
Pushed with that change
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b9
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if  you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
No longer blocks: 331959
blocking2.0: beta9+ → betaN+
Keywords: regression
Blocks: 331959
Keywords: regression
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.