Closed Bug 388280 Opened 14 years ago Closed 14 years ago
"Show (blocked popup-URL)" does not work
regress between 20070704_0524 and 20070704_0857 [range] http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1183551840&maxdate=1183564619
Seems like nsDOMEvent::GetEventPopupControlState returns openAbused from within a popupshowing event now, instead of openControlled. As popupshowing is now fired asynchronously, this is likely because the popupshowing event isn't happening during user input any more. Thus, the new blocked popup isn't opening. Not sure of the best way to fix this, but is there some reason why a chrome caller doesn't override the popup blocking check?
Comment on attachment 273235 [details] [diff] [review] use a flag to indiciate if in user input mode Seems reasonable. I assume this gives somehow better behavior than just pushing whatever the popup blocking state in ExecuteMenu() was?
Attachment #273235 - Flags: superreview?(bzbarsky) → superreview+
That is, pushing that and not changing nsDOMEvent at all.
(In reply to comment #4) > That is, pushing that and not changing nsDOMEvent at all. > Not sure what you mean. The user input state from ExecuteMenu is being pushed. Or do you mean there is a way to push the popup blocking state directly?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072323 Minefield/3.0a7pre ID:2007072323 seems to be fixed.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Probably already there, but just to confirm...
Say hello to: http://litmus.mozilla.org/show_test.cgi?id=4007.
Flags: in-litmus? → in-litmus+
Marking this as VERIFIED per comment 6.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.