1. Go to http://diversity.uoregon.edu/main.htm 2. Click "Report Discrimination" in the black bar near the top of the page. Result: the pop-up is blocked. Expected: http://darkwing.uoregon.edu/~brt/ should open in a new window. The page seems to have been generated with Dreamweaver.
Er.. does dreamweaver do this by default, or is this something the page author hacked in? Doing something onmousedown is pretty poor, since it prevents the user from dragging off to cancel the action...
Yes, it's another example of dumb HTML. It can't be a standard Dreamweaver artifact because this can't be the only Dreamweaver page on the net. And let me just say how *hilarious* it is that Mozilla pretty much works the way a browser should, except it won't let you report discrimination at the University of Oregon. Well, the capability is already coded. This behaviour can be changed simply by changing the pref of allowed popup events. The question is whether changing the default value is the right thing to do. I'm sure there exists a bad HTML counterexample for every one of our controlled events. Automatically accepting every one will weaken popup blocking. That said however, the mousedown event is more likely than most and isn't so bad: it is the result of a direct user action, after all. But as Boris said, it's in a gray area because it's not second-guessable by the user, like a click event. In my own mind I tend to classify it in the same category as keyboard events -- touch the key and get the popup. I know we want to stop somewhere short of enabling all of mousedown, mouseup, keypress, keyup, keydown. My inclination is to leave mousedown suppressed by default.
A mousedown event is a result of the *same* user action that triggers onclick. I don't understand your reluctance to enable pop-ups in onmousedown events given that they're enabled in onclick events.
I was about to write another one of my signature soliloquies waxing all elegant about my position, but then I realized it wouldn't matter, since none of them have ever changed anyone's mind. Shorter version: click and mousedown, they're not the same. click is a self-contained user end action. mousedown is supposed to be used at the beginning of a selection action, for drag & drop or for buttons that give user feedback when pressed. In theory they're altogether a different class of event. In practice they are of course mistaken for each other by beginning programmers as at the UO. I'm not dead set against adding mousedown to the default list of allowed events. But I'd much rather subscribe to a plan than suffer a knee-jerk reaction to every example of questionable event usage that a horde of dedicated web surfers can uncover given time and resources. I guess it boils down to a decision of whether to make the default set restrictive or loose. There's a good argument for loose, especially in Firefox, where the blocker is on by default. So what's the default allowed set, then? We have to add mouseup as well, since that's a more legitimate user end action event than mousedown. Is that it? Are there more? In my opinion the important ones are (timers), load, unload, focus, blur, mousemove, mouseover, mouseout, and yes, error (because of bug 239404). Maybe everything else should be allowed by default.
Dragging triggers document.onclick in addition to document.onmousedown, even if you drag out of the window, so you can't use dragging to argue that onclick pop-ups should be allowed while left-button onmousedown pop-ups should be disallowed. We have a short list of user actions that are allowed to trigger pop-ups: left-clicking within a web page, pressing enter, maybe pressing space, maybe using an accesskey. There might be several events corresponding to a single user action, but that doesn't make it any easier for sites to evade pop-up blocking.
Thank goodness I didn't go for the longer argument. OK. But I don't see this as a full response to my statement. You seem to be picking at the fleshier bits and leaving the meat alone. I just tried it. Click and drag. You get mousedown, then mouseup. click doesn't show up even after releasing the mouse, if you move it a little before releasing. I can certainly use drag and drop as part of my argument and it was at best only part of my argument. The rest has gone unanswered, especially the main point. I don't quite follow where you're going with your final paragraph. Are you arguing for a restrictive default set, or heading off in some other direction without leaving me any signposts?
> Dragging triggers document.onclick in addition to document.onmousedown, even if > you drag out of the window That's a bug, if true. Please file it, if it's not filed already. Dragging outside the window should absolutely cancel the click event. In fact, any dragging at all should really cancel click events, except we have this view capture crap going on. Note that as far as I know right-clicks fire onmousedown (but not onclick). Or did we prevent them firing both?
damn and bz, I should have been more clear when I said "dragging". I didn't trigger drag-and-drop with my test; I just moused down in the window and moused up outside of the window. I tested with data:text/html,<body onclick="alert(5)">. danm, I couldn't tell what your main point was. If your main point was that the default should be a blacklist, we've been through that in bug 197919 (see e.g. bug 197919 comment 29). I'm still arguing for a restricted set of user actions that are allowed to create pop-ups by default. But I see no need to block some events triggered by a single user action while allowing others. bz, onmousedown does fire for right-clicks. So if onmousedown were allowed to trigger pop-ups, it would have to be restricted to left-clicks in the same way that key events are restricted to enter and space.
> I didn't trigger drag-and-drop with my test; Right. That should not matter for purposes of cancelling the click event.
Well here we are, as far as I can tell: Jesse, you want mousedown to be treated like click because you think they're similar. I think they're fundamentally different. A compromise which makes sense to me is loosening up the default restrictions to include events like mousedown and mouseup, and perhaps several others. We disagree there as well; I believe you feel this way only about mousedown. This makes; I think I can truly say that it actually makes no sense to me. And there we are. Ready for input from more people, I suppose.
I have a counterexample. Click any of the video download links (the "Standard" and "Cable Modem" links) on ESPN's video archive page http://sports.espn.go.com/espn/thisissportscenter/archive . It shows the video in a new window, and it opens two identical windows in which to do this. Two? Yes, it opens one window in the link's click handler, and another in the mousedown handler. Why? Seems like a programming mistake. It's difficult to track down where the mousedown handler is added because the script on that site is deliberately obfuscated. But it's there. It's been there for months. I suspect that even the site's authors can't fix it. Blocking new windows on mousedown makes this site work properly, opening only one window. To my mind, this example and the one for which this bug was filed, and a dearth of other examples, put window-opening mousedown-handlers squarely into the category of rare and misunderstood edge cases where you'll be wrong and right no matter which decision you make. I still think mousedown and click are unrelated. But seriously, I'm actively soliciting opinions from other folks on this bug.
I'm certainly not an expert in this area, but I agree with dan that mousedown shouldn't be thought of as being "close enough" to mouse click that we treat them the same here. My vote is for supressing the pop-up unless the user actually completes the full click action. As a user, who doesn't necessarily know what's going on "behind the scenes", I don't expect a link to be followed (or in this case, to spawn a new window) unless I actually complete a click.
I'm not seeing any love for this bug other than from Jesse. I am seeing some dislike for it, and I'm getting some "be more aggressive, you big wimp." I don't like this bug, and I really don't plan to implement it, and I'd object if someone else were to implement it. So I'm closing it "won't fix" and letting my Honest Flag fly.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
*** Bug 244948 has been marked as a duplicate of this bug. ***
would there be any way to fire onmousedown popups if the user completes the click? i know that changes the effective functionality of the page, but in most cases, it's what the author intended anyway, and this would seem to be a compromise that makes both camps happy.
You're suggesting that if we get a window.open request in the mousedown handler, and open is blocked in mousedown events, that we remember the blocked request and try again when/if a mouseup event comes through for the same element, if the webpage itself hasn't issued another open request of its own, and there have been no intervening mouseups on other elements. It's probably feasible, but it makes some assumptions about the webpage writer's intent that I think could as easily be incorrect.
FYI, popups are now allowed from mousedown events, see bug 258499.
The patch for Bug 258499 was backed out, so mousedown popups are once again blocked.
*** Bug 268093 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.