Summary: | [Gtk] crash when closing page from javascript | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Dan Winship <danw> | ||||||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | eric, jmalonzo, plaes, xan.lopez | ||||||||
Priority: | P2 | Keywords: | Gtk | ||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | PC | ||||||||||
OS: | Linux | ||||||||||
URL: | http://mysterion.org/~danw/close.html | ||||||||||
Attachments: |
|
Description
Dan Winship
2009-07-19 18:58:52 PDT
I can't reproduce this, which webkit revision are you using exactly? latest svn (r46105). it was crashing before that too though. when you say you can't reproduce, does that mean the window closes the *first* time you click the button? because if not, that may also be a bug. (It doesn't actually close the window in Firefox though, so I'm not sure if there's some sort of "don't let javascript close windows it didn't open" thing going on. However, this is a simplification of another site where a window is opened by clicking on a link and then later closed by javascript in that window, so the closing is definitely correct there.) does valgrind show anything? (In reply to comment #2) > latest svn (r46105). it was crashing before that too though. Hi Dan > when you say you can't reproduce, does that mean the window closes the *first* > time you click the button? because if not, that may also be a bug. (It doesn't > actually close the window in Firefox though, so I'm not sure if there's some > sort of "don't let javascript close windows it didn't open" thing going on. Yeah that's what it's actually doing. > However, this is a simplification of another site where a window is opened by > clicking on a link and then later closed by javascript in that window, so the > closing is definitely correct there.) Is the site public? Do you mind sharing it here if it is? Thanks. (In reply to comment #3) > (In reply to comment #2) > > latest svn (r46105). it was crashing before that too though. > > > However, this is a simplification of another site where a window is opened by > > clicking on a link and then later closed by javascript in that window, so the > > closing is definitely correct there.) > > Is the site public? Do you mind sharing it here if it is? I also ran into something like this, so I created a minified testcase: http://plaes.org/files/2009-Q3/webkit-bug-27439/ PS. You can also see that window positioning is not set correctly (at least with ephy) Created attachment 33933 [details]
Patch v1
(In reply to comment #5) > Created an attachment (id=33933) [details] > Patch v1 Doesn't crash anymore, but window does not close either :( Also, real life testcase that this patch seems to fix: 1) Go to http://www.jassi.ee/ 2) Click on the map 3) Either crash happens after a click or when you try to close the popup window (In reply to comment #6) > (In reply to comment #5) > > Created an attachment (id=33933) [details] [details] > > Patch v1 > > Doesn't crash anymore, but window does not close either :( Embedders need to listen to close-web-view to either destroy or hide their windows which I don't think ephy does atm. (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Created an attachment (id=33933) [details] [details] [details] > > > Patch v1 > > > > Doesn't crash anymore, but window does not close either :( > > Embedders need to listen to close-web-view to either destroy or hide their > windows which I don't think ephy does atm. Wouldn't it be with this patch *mandatory* that you handle the signal? Otherwise you'd leak the view object, which used to be unreffed by closeWindowSoon until now. If that's the case you should make the documentation more specific about that. (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > Created an attachment (id=33933) [details] [details] [details] [details] > > > > Patch v1 > > > > > > Doesn't crash anymore, but window does not close either :( > > > > Embedders need to listen to close-web-view to either destroy or hide their > > windows which I don't think ephy does atm. > > Wouldn't it be with this patch *mandatory* that you handle the signal? Now it's kinda mandatory. How does a WebView created by create-web-view get freed prior to when this signal was introduced? > Otherwise you'd leak the view object, which used to be unreffed by > closeWindowSoon until now. If that's the case you should make the documentation > more specific about that. I did. * + * It is also recommended that #WebKitWebView::close-web-view be handled + * to hide the #WebKitWebView. + * Maybe add something like "free the WebView you created in create-web-view"? (In reply to comment #9) > Now it's kinda mandatory. How does a WebView created by create-web-view get > freed prior to when this signal was introduced? > Well, in the general case it's handled by the client, since it's the client who created the view right? But in the case of the windows destroyed by window.close() the code that emits the signal would destroy the view itself, so in theory you didn't need to do anything (although this is probably too simplistic anyway, since for popups in new windows you'd need to get rid of the toplevel anyway...). > > Otherwise you'd leak the view object, which used to be unreffed by > > closeWindowSoon until now. If that's the case you should make the documentation > > more specific about that. > > I did. > > * > + * It is also recommended that #WebKitWebView::close-web-view be handled > + * to hide the #WebKitWebView. > + * > > Maybe add something like "free the WebView you created in create-web-view"? Yeah, I read that, but I meant explaining explicitly that you have to free/hide the view in the callback yourself. 'Recommended' sounds a bit like 'it would be good if you do it, but you don't have to', but I don't think that's the case now? Also, I think it would be good to have a test (or tests) about this (we can do it after we land the patch though). (In reply to comment #10) > (In reply to comment #9) > > Now it's kinda mandatory. How does a WebView created by create-web-view get > > freed prior to when this signal was introduced? > > > > Well, in the general case it's handled by the client, since it's the client who > created the view right? Right. > But in the case of the windows destroyed by > window.close() the code that emits the signal would destroy the view itself, so > in theory you didn't need to do anything (although this is probably too > simplistic anyway, since for popups in new windows you'd need to get rid of the > toplevel anyway...). > > Maybe add something like "free the WebView you created in create-web-view"? > > Yeah, I read that, but I meant explaining explicitly that you have to free/hide > the view in the callback yourself. 'Recommended' sounds a bit like 'it would be > good if you do it, but you don't have to', but I don't think that's the case > now? Right. I'll mention that it's mandatory. > Also, I think it would be good to have a test (or tests) about this (we can do > it after we land the patch though). I'll try to come up an updated patch with test in the next couple of days. Thanks for the review. Comment on attachment 33933 [details]
Patch v1
Clearing review. I'll update the patch based on Xan's feedback.
Created attachment 34486 [details]
updated patch, no test
(In reply to comment #13) > Created an attachment (id=34486) [details] > updated patch, no test I'll add the test when I get more time. Created attachment 34887 [details]
updated signal doc
Comment on attachment 34887 [details]
updated signal doc
I realise i'm not a gtk person, but this patch seems obvious enough to me, r=me
(In reply to comment #16) > (From update of attachment 34887 [details]) > I realise i'm not a gtk person, but this patch seems obvious enough to me, r=me Thanks, somehow most of my bugmail of the last days went to the spam folder an I missed this (among other things). Comment on attachment 34887 [details] updated signal doc Clearing flags on attachment: 34887 Committed r47493: <http://trac.webkit.org/changeset/47493> All reviewed patches have been landed. Closing bug. |