This is related to 14714 which has to do with selection behavior. This bug is for the behavior of opening up windows. I was loading http://www.netscape.com/ in apprunner and playing with selection. While I was in the middle of making a drag selection (the mouse button was still pressed), a new window popped up. I think that new windows should not popup while any mouse button is down. (Disclaimer: the term "windows" used above means "top-level window" or "windows" in a Macintosh sense) German: can you make a ruling regarding whether windows should be able to be popped up while the mouse is down? If you feel that the current behavior is acceptable, please mark this as invalid. If you feel that the current behavior should change, please indicate so and reassign to danm@netscape.com.

I am in for german (he is way toooooo busy updating the specs) on this bug. I talked to german and we all agreed that the current behavior here is wrong. A new window should not popup while any mouse button is down.Reassign it to danm. Thanks!

Not much to go on from the description. So I imagine this window's opening was triggered by the inopportune firing of some JavaScript timeout. I'm not sure what it means to freeze execution of the JS thread at certain points in response to hardware conditions. Sending to Brendan for consideration.

I don't know where to start. There is no JS thread apart from the UI/layout thread for DOM JS. Is that helpful? Danm, what's really going on here? /be

Reassigning to German for UE advice. Do we have a usability bug here? I think so, but others do not. Please assign back and I'll find the right person to own it (or give it to danm@netscape.com ;-). /be

It is a usability bug in a sense that while the mouse is down no other non-background activities should happen. E.g. it's OK to show continued progress on a progress meter, but opening windows should deferred until the mouse button is released. Mousing down indicates the users is about to make a controlling action and the system is supposed to 'listen', if you exucse my sloppy wording. It would be great if we could fix that!

Ugh, this sounds like we need more modality: when selecting (and dragging? it seems so), other events must queue up until the select or drag is done. Cc'ing some selection and drag gurus for advice. /be

how does this work in 4.x? at least on macos in 4.5, we do the right thing.

That's probably because in 4.5, we're not handling any events while the mouse is down; we're in a while (StillDown()){} loop. In Mozilla, on the other hand, we handle events continually while the mouse is down, so other stuff can happen.

right, of course, duh ;) That means our solution needs to be XP somehow, but where it should go I haven't the foggiest.

Travis, can you sit on this while I'm on sabbatical (or better yet, fix it, or pass it to someone who can, once the XP EventLoop stuff is done)? Thanks, /be

Let's consider this post-beta 1 ...

Could we also disable alert()s and include "when the user has made a right- click menu" to the list of times when things shouldn't pop up? See my friend's page, http://www.ben2.ucla.edu/~dabruin/index2.htm , which uses an annoying trick intended to make it hard for people to view his source.

Move to M16 for now ...

Flipping to peter to assign, I don't think I really own this.

Another bug for Mr. Window - danm

moving to m18

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

See also bug 40535.

To paraphrase someone, the future is now. Can we get a more up to date prognosis for this bug?

window.open should just check to see if the mouse is down, if it is then it should use setTimeout to execute again later.

See also bug 72084, "There is no way to disable the context menu upon right- click".

Is this going to need bug 78248 - "[RFE] API to determine if a mouse button is pressed"?

Dean: Most likely, if there isn't any xpcom API for this. If there is a way to determine that, then I would assume that 78248 would be marked invalid. Since it isn't, then this bug should depend on that. It might be faulty logic, but that's my opinion at least. If you can't detereming the mouse is down, then there is no way to complete this bug. The solution would be, imho, to have one of the classes in the beginning of the event path keep some flags on which mouse buttons are down.

see bug 100180 too