Closed
Bug 1441466
Opened 6 years ago
Closed 6 years ago
[regression] Middle-clicking link (to open in new tab) blocked by pop-up blocker
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1004633
People
(Reporter: post+mozilla, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180222170353 Steps to reproduce: Since recently (maybe 4 to 6 weeks), in some websites, when I middle-click some of the links, instead of opening the link in a new tab, the pop-up blocker information bar appears. So far I have noticed this on heise, for example you can go to https://www.heise.de/newsticker/meldung/Domain-Pulse-Registries-sperren-proaktiv-und-hoffen-auf-weitere-Haftungsfreiheit-3977934.html and middle-click "Rekordzahl von Domains". Actual results: A pop-up blocker information bar appears. Expected results: A new tab should have been opened. This happens for all links in the text body of news on this website; it does not happen for links in the sidebars or for links from the main page to the individual article. I tried disabling my adblocker, that made no difference. This is a regression; opening links has worked fine in earlier versions of Firefox.
Comment 1•6 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 20180226230123 (In reply to Ralf Jung from comment #0) > This is a regression I doubt it. I was able to reproduce this as far back as Firefox 29. There are also at least 2 other bugs about this, one 6 years old and the other 4 years old. Feel free to try to find the regression range though [1]. A few notes: * This is specific to middle-clicking. Ctrl+click works fine. * This is specific to third-party links (at least on the site provided as an example). The aforementioned "Rekordzahl von Domains" link is blocked, as is "Alliance for Creativity and Entertainment" on another page [2]. Links to the same domain are not blocked however. * Third-party links on other sites are not blocked when middle-clicked. For example, "Austere Luminosity of Chinese Classical Furniture" on this Wikipedia page [3]. * Bug 745329 - it looks like this should be marked as a duplicate of it. * Bug 1004633 - nearly identical, except Click+click doesn't work either. (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from bug 745329, comment #8) > The native popup blocker doesn't block "middle click". It _does_ block > attempts to call window.open() from inside middle click, though. Is the > page doing that (and calling preventDefault to prevent the normal Firefox UI > handling of middle click)? I think so, but please check. In the Inspector pane, click the [ev] button next to '<html lang="de">'. Expand the first instance of 'click'. It shows function(t) { var e = t.target; "A" === e.tagName && /external/.test(e.getAttribute("rel")) && /^(http|\/)/.test(e.getAttribute("href")) && (t.preventDefault(), window.open(e.getAttribute("href"), "_blank")) } [1] https://mozilla.github.io/mozregression/documentation/usage.html [2] https://www.heise.de/newsticker/meldung/30-internationale-Medienunternehmen-bilden-Allianz-gegen-Piraterie-3743059.html [3] https://en.wikipedia.org/wiki/Science_and_technology_of_the_Song_dynasty
I am surfing that website for many, many years and have opened links from their articles regularly. I am pretty much always open links by middle-clicking (unless I'm using a touchpad). I am sure this used to work.
Given your tests with older versions, this means something changed in their website?
> In the Inspector pane, click the [ev] button next to '<html lang="de">'. Expand the first instance of 'click'. It shows
For me it shows
function(r) {
if (a && this.removeEventListener(t, e, n), r.__target || Ae(r), c !== this) {
var i = Object.getOwnPropertyDescriptor(r, "currentTarget");
Object.defineProperty(r, "currentTarget", {
get: function() {
return c
},
configurable: !0
})
}
if (r.composed || -1 < r.composedPath().indexOf(c))
if (ke(r) && r.target === r.relatedTarget) r.eventPhase === Event.BUBBLING_PHASE && r.stopImmediatePropagation();
else if (r.eventPhase === Event.CAPTURING_PHASE || r.bubbles || r.target === c || c instanceof Window) {
var s = "function" === o ? e.call(c, r) : e.handleEvent && e.handleEvent(r);
return c !== this && (i ? (Object.defineProperty(r, "currentTarget", i), i = null) : delete r.currentTarget), s
}
}
Comment 3•6 years ago
|
||
> Given your tests with older versions, this means something changed in their website? Probably, yes. I'm trying to understand comment 1. Are you saying you _do_ have a listener that looks like that? If you do, then of course it would cause this behavior. I'm not seeing such a listener, though... (And I have middle button, so no way to test the behavior.)
Flags: needinfo?(bzbarsky)
Comment 4•6 years ago
|
||
Ah, a listener like the one described in comment 1 is there; it's just on document, not <html>. From https://www.heise.de/assets/heise/heise/js/heise.js?a15eb42a1212eefec783 : window.document.addEventListener("click",function(t){var e=t.target;0===t.button&&"A"===e.tagName&&"_blank"!==e.getAttribute("target")&&"external"===e.getAttribute("rel")&&/^(http|\/)/.test(e.getAttribute("href"))&&(t.preventDefault(),window.open(e.getAttribute("href"),"_blank"))})} but this one checks for left-click specifically (see the 0===t.button test). Just to check, is this problem still reproducible on this page?
> I'm trying to understand comment 1. Are you saying you _do_ have a listener that looks like that?
Didn't you ask me to look for a listener like that? You said I'd find something that looks like
function(t) {
var e = t.target;
"A" === e.tagName && /external/.test(e.getAttribute("rel")) && /^(http|\/)/.test(e.getAttribute("href")) && (t.preventDefault(), window.open(e.getAttribute("href"), "_blank"))
}
but I did not. I found something else instead. Or maybe you were saying something else and I misunderstood?
> Just to check, is this problem still reproducible on this page?
The one I linked above? No in fact not. Did they change their website again?
Websites changing so quickly kind of makes debugging hard...^^
Comment 7•6 years ago
|
||
> Didn't you ask me to look for a listener like that? I think "Gingerbread Man" was saying he was seeing a listener like that, but I wanted to confirm my understanding there. > Did they change their website again? So far it's sounding like they did...
So as far as I'm concerned this can be closed as a duplicate of bug 1004633.
Comment 9•6 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 20180227100126 (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #3) > I'm trying to understand comment 1. Are you saying you _do_ have a listener > that looks like that? There was such an event listener when I posted comment 1, but not anymore. > Just to check, is this problem still reproducible on this page? No. Nothing blocked when middle-clicking the links mentioned at comment 0 and comment 1. (In reply to Ralf Jung from comment #8) > So as far as I'm concerned this can be closed as a duplicate of bug 1004633. That one is still reproducible, so let's.
Assignee | ||
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•