The default bug view has changed. See this FAQ.

Firefox 5: Div onclick() doesn't work

VERIFIED FIXED in mozilla7

Status

()

Core
DOM
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Shawn, Unassigned)

Tracking

5 Branch
mozilla7
All
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build ID: 20110413222027

Steps to reproduce:

Updated browser to Firefox 5.


Actual results:

I have a div control that uses an onclick() event that has worked perfectly in prior versions of Firefox (verified in 4.0.1) and works correctly in all versions of IE.  However, on machines that have updated to Firefox 5, the onclick() event no longer works.


Expected results:

Clicking the div should have fired the onclick() event.
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
This works fine as far as I can tell.  Can you attach a testcase showing the problem, please?
OS: Other → Windows 7
(Reporter)

Comment 2

6 years ago
You just want some markup?
(Reporter)

Comment 3

6 years ago
<div onclick='transferPageWithReferrer(SOMEPAGE)'/>

The div is showing the hand cursor and I can see the correct location of the transferPageWithReferrer in the page source but on mouseover.  We've had several of our products indicate similar issues.

I've added an alert to the onclick event and it appears the onclick() event actually is being fired, but in this instance we are injecting an anchor tag to the page using document.createElement("a") and perhaps this is where the break is occurring.
(Reporter)

Comment 4

6 years ago
ok so it appears that the Firefox issue is actually with the following rather than the onClick() event.  It appears that the issue is the

function transferPageWithReferrer(url) {
location.href = url;
}

is not working in Firefox 5.
> You just want some markup?

Generally, yes.  When filing a bug, it's a good idea to provide a link to a page showing the problem or attach the markup using the "Add an attachment" link.

I really doubt that you code looks like what you pasted in comment 4, especially given the business about createElement("a") in comment 3, which is conspicuously absent from comment 4.

Does it perhaps look more like bug 666985 comment 5?
(Reporter)

Comment 6

6 years ago
lol... that's exactly where its breaking:

function navigateWithReferrer(url) {
        var fakeLink = document.createElement("a");
        if (typeof (fakeLink.click) == 'undefined') {
            location.href = url
        } else {
            fakeLink.href = url;
            document.body.appendChild(fakeLink);
            fakeLink.click()
        }
    }

Another developer used this approach to forward a page from a div onclick() event.
(Reporter)

Comment 7

6 years ago
It seems that changing the above to: 

function navigateWithReferrer(url) {
        var fakeLink = document.createElement("a");
        if (document.createEvent) {
            location.href = url
        } else {
            fakeLink.href = url;
            document.body.appendChild(fakeLink);
            fakeLink.click()
        }
    }

has corrected the problem and the links are transferring again.
I have to ask... why are you not just always setting location.href?  What browser doesn't send a referrer on location.href sets?

In any case, the fix for bug 666604 fixed this.
Blocks: 583514
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Depends on: 666604
Resolution: --- → FIXED
status-firefox6: --- → fixed
Target Milestone: --- → mozilla7
status-firefox6: fixed → ---
(Reporter)

Comment 9

6 years ago
believe it or not, location.href actually has a minor to moderate performance difference over this method.  Not sure why.  I actually took out all of the above and just used document.location.href = url and although the transfer occurred in both FF and the IE browsers, it took them awhile.

Thanks for your help.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
> believe it or not, location.href actually has a minor to moderate performance
> difference 

Having measured and profiled both, I do not in fact believe it... ;)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

6 years ago
:)
I wouldn't have thought so either, but, at least in this instance, it was sometimes up to 20-30 seconds difference.

Glitch in the matrix I suppose.
Thanks for all the help.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Comment 12

6 years ago
Created attachment 557431 [details]
Test case containing all 3 examples given by the reporter

Comment 13

6 years ago
Verified fixed on:
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20100101 Firefox/7.0

Steps to verify:
 1. Open the test case attached in the previous comment.
 2. Tap on each “Click here...” string (each string represents a different div with a distinct onclick method).
The corresponding web page is opened for each div (1-google.com, 2-gmail.com, 3-yahoo.com).
Status: RESOLVED → VERIFIED

Updated

6 years ago
Attachment #557431 - Attachment is obsolete: true

Comment 14

6 years ago
Created attachment 557460 [details]
Test case containing all 3 examples given by the reporter
You need to log in before you can comment on or make changes to this bug.