Closed Bug 311479 Opened 20 years ago Closed 20 years ago

onBlur and onClick both doing self.close() crashes firefox when used in popup window

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dooglus, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(1 file)

Possible patch
6.49 KB, patch
mrbkap
: review+
jst
: superreview+
asa
: approval1.8rc1+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1 I made this tiny web page which reliably crashes firefox: <html><body onBlur="self.close()" onClick="self.close()"> <a href="javascript:;" onClick="javascript:window.open('crash.htm')"> click here, then click the pop-up window to see a crash</a> </body></html> I've uploaded a copy here: http://s89213869.onlinehome.us/crash.htm When you click the webpage's link, it opens a copy of itself in a new window. Clicking anywhere in that new window crashes firefox. Perhaps both the 'onBlur' and 'onClick' actions are triggering, with the 2nd of them trying to access something that the 1st has already released. I've tried this in ubuntu breezy's 1.0.7 and in the mozilla builds of 1.50beta1 and 1.50beta2 and all 3 crash. [ originally reported here: http://bugzilla.ubuntu.com/show_bug.cgi?id=17221 ] Reproducible: Always Steps to Reproduce: 1. visit http://s89213869.onlinehome.us/crash.htm 2. click the link to make a new window 3. click anywhere in the new window to crash firefox Note that the crash doesn't happen if firefox is set to "force links that open windows to open in a new tab" in the 'tabs' tab of the preferences dialog. Actual Results: "Segmentation fault"
I just noticed that although setting "force links that open windows to open in a new tab" in the 'tabs' tab of the preferences dialog stops the crash from happening when you click on the new window, the crash still happens if you "alt-tab" away from the new window instead.
This regressed between 2005-10-02 and 2005-10-05. I very much suspect bug 310552 to be the cause of this bug. (it doesn't crash by the way, Firefox is just closing, but that should absolutely not happen here)
Assignee: nobody → general
Blocks: 310552
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Flags: blocking1.8.1?
Keywords: regression, testcase
OS: Linux → All
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
No crash for me: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Flags: blocking1.8rc1?
(In reply to comment #2) I see the words "Segmentation fault" when firefox "closes". That's what lead me to think it was a crash. Oh, and the 'talkback' thingy opens up, too. See talkback incidents with the following IDs, which I generated while whittling down a huge web page to the testcase I presented above: 1.50beta2: TB10335294M TB10335271H TB10334317M TB10334314G 1.50beta1: TB10333520M TB10331714Q TB10331695W TB10331670Z
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1 Hmm, this seems to work for me: When I click into the new window (step 3), the window closes, but the original window (from step 1) is still there. No crash and Firefox does not close either. I see some warnings in the JS console: "Scripts may not close windows that were not opened by script." This is expected, however, since the first window (step 1) also has the onclick/onblur handlers and they are causing these warnings.
(In reply to comment #5) > This is expected, however, since the first window (step 1) > also has the onclick/onblur handlers and they are causing these warnings. When I originally saw the bug it was caused by one page opening another. I reduced it to one page opening itself to make a smaller test case. I've made a new case using 2 different files. The first file now doesn't have any onclick/onblur handlers. The first page is 'crash2.htm': --- <html><body> <a href="javascript:;" onClick="javascript:window.open('crash3.htm')"> click here to open a pop-up window</a> </body></html> --- And that opens 'crash3.htm': --- <html><body onBlur="self.close()" onClick="self.close()"> click anywhere in this window to see the crash </body></html> --- I have uploaded them both as before. Use this link: http://s89213869.onlinehome.us/crash2.htm If clicking on the 2nd window doesn't cause a crash, try taking focus away from firefox, by alt-tabbing to a different window for example. That crashes firefox for me even if the 2nd window was forced to open in a tab.
Still no crash or other misbehaviour for me here in Linux on the second test case, neither on click nor on Alt-Tab. I did not force windows to open in new tabs (the warnings have gone away, btw). This is with the official 1.5 beta 2 release. Maybe someone else has more luck reproducing the problem. Stack trace from the last TB report (the others are very similar): 0x69665f61 nsWindow::DispatchDeactivateEvent() [/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsWindow.cpp, line 4316] nsWindow::OnContainerFocusOutEvent() [/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsWindow.cpp, line 1673] focus_out_event_cb() [/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsWindow.cpp, line 3748]
Oops, I meant blocking 1.8rc1. dooglus, there might be two separate issues here, as I see it now: - a windows issue, that just regressed recently, which causes all windows too close with the testcase. - a linux issue, that causes a crash with your setup, and that doesn't seem to have regressed recently.
Flags: blocking1.8.1?
Have you tried making a new profile? The bug happens for me in a new profile, as well as my old one. I'm using the official linux build of 1.50beta2, which I downloaded a few hours ago from http://64.12.204.21/pub/mozilla.org/firefox/releases/1.5b2/linux-i686/en-US/firefox-1.5b2.tar.gz If I force new windows to open in tabs, then clicking the new tab only closes the new tab, not all windows. Is there anything I can do to help diagnose the crash?
So the upshot of it is that we end up with two copies of ReallyCloseWindow set as termination functions on the JSContext. We should probably not do that...
Attached patch Possible patch — — Splinter Review
This fixes the crash2 thing for me (on Linux). The first testcase I can't reproduce a problem with to start with.... Martijn, does this fix whatever issues you see here?
Attachment #198886 - Flags: superreview?(jst)
Attachment #198886 - Flags: review?(mrbkap)
I just tried Boris' "Possible patch" attachment, and it doesn't work completely: First of all I grabbed the trunk from CVS and built it without the patch to see how that looks. I still see both my testcases failing, but neither of them kill firefox with a segfault any more - they leave the process running, but with no GUI showing. After applying the patch the behaviour is musch improved, but: If you force new windows to go to a new tab using the 'tab' tab in the preferences dialog, then click the link in either test case, a new tab appears, and gets focus. If you then switch back to the original tab, the new tab is supposed to close itself (due to its 'OnBlur' handler) but it doesn't. Finally, if you use the 'tab' tab in 'preferences' to set that new windows should open in "the same tab/window as the link", then visit crash2.htm, and click the link, and then type control-t to make a new tab, the previous tab doesn't close itself immediately, even though it has lost focus. I can type control-t as many times as I like, and the 'crash3.htm' tab stays there. It's not until I click in the location bar that the 'crash3.htm' tab closes itself.
Yeah.. Those prefs to force stuff to load in tabs are a bloody hacky mess. I'll try to look into it sometime, but no guarantees.
> If you then switch back to the original tab, the new tab is supposed to close > itself (due to its 'OnBlur' handler) but it doesn't. This worksforme on Linux with crash2.htm and crash1.htm > Finally, if you use the 'tab' tab in 'preferences' to set that new > windows should open in "the same tab/window as the link" This worksforme with crash2.htm. On crash1.htm, Firefox shuts down as soon as I click the link, since we close the only window around...
(In reply to comment #11) > Martijn, does this fix whatever issues you see here? No, all Firefox windows still close with that patch.
OK. Sounds like Windows behaves differently here; someone with a Windows build will have to look. :(
Comment on attachment 198886 [details] [diff] [review] Possible patch + // XXXbz now that we have mHavePendingClose, is this needed? Good question. Seems safe to leave in tho, I'd rather err on the side of caution here, and I don't have the time to figure out exactly what, if anything, would break if we took this out now. sr=jst
Attachment #198886 - Flags: superreview?(jst) → superreview+
Flags: blocking1.8rc1? → blocking1.8rc1+
Assignee: general → bzbarsky
Asa, I can't work on a bug I can't reproduce..... See comment 16. If there's no one else to work on this, I'll try to set up a build env finally, but that won't be happening until sometime next week at best.
Assignee: bzbarsky → general
Johnny, can you help here?
So realistically... My patch fixes the one supported mode of operation, right? If people are using the "force ..." options, they're sort of doing it at their own risk, and all sorts of stuff breaks, last I checked. Given also that this is not a regression over 1.7.x (and earlier), and that this is not exploitable, I just don't think we should be blocking on this.
(In reply to comment #20) > If people are using the "force ..." options, they're sort of doing it at their > own risk, and all sorts of stuff breaks, last I checked. That isn't made clear. The 'force' options are available from the preferences dialog. They aren't marked as being dangerous. Is there an existing but report for this "all sorts of stuff" that's broken? Perhaps that's what needs to be blocked on rather than this.
> The 'force' options are available from the preferences dialog. That's not a Core bug.... > Is there an existing but report for this "all sorts of stuff" that's broken? Yes. It's not getting fixed for 1.8, for various reasons (mostly having to do with it being about 6 months too late for that sort of thing).
No crash here. Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Comment on attachment 198886 [details] [diff] [review] Possible patch r=mrbkap
Attachment #198886 - Flags: review?(mrbkap) → review+
Comment on attachment 198886 [details] [diff] [review] Possible patch Checked this in. This is probably the point at which we start regretting lumping several distinct issues into one bug. :(
Attachment #198886 - Flags: approval1.8rc1?
Attachment #198886 - Flags: approval1.8rc1? → approval1.8rc1+
Yesterday I had crashes After today's update nolonger seeing it Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051015 Firefox/1.6a1
on another PC i am still having prob, even after all update Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051015 Firefox/1.6a1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051016 Firefox/1.4.1 ID:2005101605 i tested it firefox does not crash but the windows does close or if you open in a tab, the tab closes
Comment on attachment 198886 [details] [diff] [review] Possible patch Checked this patch in on the 1.8 branch. But the fixed1.8 keyword really doesn't apply here.... :(
this bug no longer blocks since we've got what we need for the branch. removing blocking flag to get this off our open blockers list.
Flags: blocking1.8rc1+
Actually, I think this is also fixed for windows now. I can't reproduce the behavior anymore mentioned in comment 2 with my 2005-10-16 trunk build.
Well, this is fixed. I must have done something wrong when I applied the patch in my debug build. If someone can still reproduce this, please reopen.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 312517 has been marked as a duplicate of this bug. ***
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: