User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 The FF popup blocker permits a new target window to open if a webpage link is interactively clicked, but if the 'click' event is injected to that same target element (A href link) via initMouseEvent from a trusted JS Firefox extension, it blocks the window open event as a popup. After tracing through the code path in lxr, I've wasn't able to nail down why the window open action is getting blocked for my synthetically created click event to the anchor tag. Reproducible: Always - the synthetic event is being created in JS via a FF extension. - when the 'dom.disable_open_during_load' preference is set to false, the new browser window opens fine for the injected event; if set to true, the window open is blocked. - the page is already fully loaded when the click event is actually dispatched. - the 'dom.popup_allowed_events' preference contains everything I could throw at it: "change click dblclick mouseup reset submit mouseover mouseout mousedown". - setting 'dom.disable_open_click_delay' to any number of milliseconds doesn't appear to matter (0, 20, 200, 1000, 20000, etc). - since the click event is initiated via my extension, the source event is trusted - nothing I could do in venkman to step through or introduce timing delays between the UI thread and network threads would do anything to help
(In reply to comment #0) > After tracing through the code path in lxr, I've wasn't able to nail down why > the window open action is getting blocked for my synthetically created click > event to the anchor tag. Could (the patch for) Firefox bug 263960 be of help?
> Could (the patch for) Firefox bug 263960 be of help? That bug doesn't appear to help with this issue, since its focus is to stop a synthetic click popup, and my goal is to allow it. The problem here is that the W3C specs state specifically that a synthetically created event ('click') should have the same outcome as that produced through direct user interaction on the target element. This is not the case. As stated, the popup comes from a legitimate a href event and opens a window when clicked interactively (not blocked); but when that same event is synthetically injected, the window open is blocked and should not be. Bottom line is that if the source is trusted (as it is with a FF extension), the synthetic click event to a link which opens a window should not be treated as though it were some evil flash window pop event. This breaks any extension that is trying to automate a link click for its user.
12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: events → jst
Flags: blocking1.9? → blocking1.9-
Actually, this could interfere with automated UI testing in an unfortunate way. So I think we might really want to fix this....
If that's the case please do renominate. Jst was gonna take a look at this so chances are that it'll get fixed either way.
Well, as things stand one can't write mochitests for popup blocking, for example... I do think this is wanted-1.9, not blocking.
You need to log in before you can comment on or make changes to this bug.