Closed
Bug 254894
Opened 20 years ago
Closed 20 years ago
Menu automatically closes when using xmlhttprequest in an interval timer
Categories
(Core :: Widget: Win32, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: martijn.martijn, Assigned: neil)
References
Details
Attachments
(2 files, 1 obsolete file)
849 bytes,
text/html
|
Details | |
737 bytes,
patch
|
deanis74
:
review+
darin.moz
:
superreview+
benjamin
:
approval1.8b3+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040808 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040808 Firefox/0.9.1+
See upcoming testcase. I'm not sure in which component this bug should be.
This testcase causes the menu to close again (after 2 seconds which is the timer
interval of the script), after you have opened it.
It happens because of:
var req = new XMLHttpRequest();
req.open("GET", this.location.href,false);
req.send(null);
Reproducible: Always
Steps to Reproduce:
1. Load testcase
2. Open any menu with the mouse.
3. Stay on the same position of where you clicked to open the menu
Actual Results:
Menu closes automatically (max 2 seconds after clicking).
Expected Results:
Should not close menu automatically.
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
Aargh! the previous one was wrong. This one should show the bug.
Attachment #155583 -
Attachment is obsolete: true
Reporter | ||
Comment 3•20 years ago
|
||
Probably related to all the
document-refresh-stealing-keyboard-focus-from-textbox issues.
Blocks: 140346
Component: Browser-General → Event Handling
Comment 4•20 years ago
|
||
Could pushing a new event queue somehow close the menu?
Assignee | ||
Comment 5•20 years ago
|
||
This is a windows-only bug, according to my stack trace. Investigating...
Assignee | ||
Comment 6•20 years ago
|
||
(In reply to comment #4)
> Could pushing a new event queue somehow close the menu?
It sure could. In Windows, creating an event queue creates a window, but the
widget code dismisses all popups whenever a window is moved, sized or created.
Assignee | ||
Comment 7•20 years ago
|
||
So maybe we should only make the dismissal code work for visible windows?
Comment 8•20 years ago
|
||
Over to Windows widget... We should do _something_, certainly; having event
queue pushing closing popups is no good.
Assignee: general → win32
Component: Event Handling → Widget: Win32
QA Contact: general → ian
(In reply to comment #7)
> So maybe we should only make the dismissal code work for visible windows?
That seems logical to me.
Comment 10•20 years ago
|
||
*** Bug 293741 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 11•20 years ago
|
||
Assignee: win32 → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Attachment #186874 -
Flags: review?(dean_tessman)
Comment 12•20 years ago
|
||
Comment on attachment 186874 [details] [diff] [review]
Proposed patch
Assuming it works, r=me. Alternatively, couldn't we kill a level of braces by
changing this to:
if (!(gRollupListener && gRollupWidget && IsWindowVisible(inWnd)))
return FALSE;
Or something similar?
Attachment #186874 -
Flags: review?(dean_tessman) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #186874 -
Flags: superreview?(darin)
Comment 13•20 years ago
|
||
Comment on attachment 186874 [details] [diff] [review]
Proposed patch
rs=darin
Attachment #186874 -
Flags: superreview?(darin) → superreview+
Assignee | ||
Comment 14•20 years ago
|
||
Comment on attachment 186874 [details] [diff] [review]
Proposed patch
Trivial fix.
Attachment #186874 -
Flags: approval1.8b3?
Updated•20 years ago
|
Attachment #186874 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 15•20 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•20 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•