On Thu, Sep 25, 2008 at 11:14:28PM -0700, Donald Chai wrote:
On Thu, Sep 25, 2008 at 3:58 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
I just came accross an easy to reproduce segfault, that's present since long ago.
Middle-clicking works OK right?
Well, try middle-clicking a link with a two mouse button (i.e. pressing both at the same time). The link menu stays open and after a second click (e.g. left click to make it dissapear) it segfaults.
[...]
I see this problem as well. If I very quickly press the left then right mouse button (NOT at the same time), then I get a segfault. Dillo seems to try to select some text on the old page, after the new page is loaded.
This hinted me towards a timing issue and found this way to crash dillo (most probably akin to the "middle-click" bug): 1.- Left click over a remote URL link (to have some time while DNS is resolving) 2.- Move the mouse pointer out of the link and right-click to get the popup menu, before the new page starts downloading. 3.- Once the new page starts to show, click again to get rid of the popup, and it'll crash. -- Cheers Jorge.-
Jorge wrote:
This hinted me towards a timing issue and found this way to crash dillo (most probably akin to the "middle-click" bug):
1.- Left click over a remote URL link (to have some time while DNS is resolving) 2.- Move the mouse pointer out of the link and right-click to get the popup menu, before the new page starts downloading. 3.- Once the new page starts to show, click again to get rid of the popup, and it'll crash.
What a coincidence! I finally got around to making a patch for that last night. (I'd known about that one for a while...)
I wrote:
Jorge wrote:
This hinted me towards a timing issue and found this way to crash dillo (most probably akin to the "middle-click" bug):
1.- Left click over a remote URL link (to have some time while DNS is resolving) 2.- Move the mouse pointer out of the link and right-click to get the popup menu, before the new page starts downloading. 3.- Once the new page starts to show, click again to get rid of the popup, and it'll crash.
What a coincidence! I finally got around to making a patch for that last night. (I'd known about that one for a while...)
Here, you can give it a try. It took until yesterday to finally poke at it long enough to find the problem because the backtrace you get is very misleading. It dies down below Widget::buttonPress (EventButton *event), and of course you just pressed the button to get rid of the popup -- but it's really the old button press that popped up the menu. First it went down buttonPressImpl and caused the popup, which doesn't return until the menu goes away, and second it goes down eventEmitter.emitButtonPress...but the widget and its emitter are gone. So I threw timeout at it and made copies of things in popup_*.
I wrote:
@@ -280,20 +284,19 @@ void a_Menu_page_popup(BrowserWindow *bw pm->end(); }
- if (bugs_txt == NULL) + if (bugs == TRUE) view_page_bugs_item->deactivate();
view_page_bugs_item->activate();
else view_page_bugs_item->activate();
view_page_bugs_item->deactivate(); Ooh, a bug! I was trying to get this out relatively quickly because it was on topic and because we know a freeze will be coming at some point here...ah well...
On Fri, Sep 26, 2008 at 09:29:00PM +0000, corvid wrote:
I wrote:
Jorge wrote:
This hinted me towards a timing issue and found this way to crash dillo (most probably akin to the "middle-click" bug):
1.- Left click over a remote URL link (to have some time while DNS is resolving) 2.- Move the mouse pointer out of the link and right-click to get the popup menu, before the new page starts downloading. 3.- Once the new page starts to show, click again to get rid of the popup, and it'll crash.
What a coincidence! I finally got around to making a patch for that last night. (I'd known about that one for a while...)
Here, you can give it a try.
It took until yesterday to finally poke at it long enough to find the problem because the backtrace you get is very misleading. It dies down below Widget::buttonPress (EventButton *event), and of course you just pressed the button to get rid of the popup -- but it's really the old button press that popped up the menu. First it went down buttonPressImpl and caused the popup, which doesn't return until the menu goes away, and second it goes down eventEmitter.emitButtonPress...but the widget and its emitter are gone.
Ah right. I thought it was related to the old popup, but I could not figure out where the buttonPress() came from, it showed button 3 pressed where I had pressed button 1 to get rid of the popup. Thanks for the explanation. Johannes
On Fri, Sep 26, 2008 at 09:29:00PM +0000, corvid wrote:
I wrote:
Jorge wrote:
This hinted me towards a timing issue and found this way to crash dillo (most probably akin to the "middle-click" bug):
1.- Left click over a remote URL link (to have some time while DNS is resolving) 2.- Move the mouse pointer out of the link and right-click to get the popup menu, before the new page starts downloading. 3.- Once the new page starts to show, click again to get rid of the popup, and it'll crash.
What a coincidence! I finally got around to making a patch for that last night. (I'd known about that one for a while...)
Here, you can give it a try.
It took until yesterday to finally poke at it long enough to find the problem because the backtrace you get is very misleading. It dies down below Widget::buttonPress (EventButton *event), and of course you just pressed the button to get rid of the popup -- but it's really the old button press that popped up the menu. First it went down buttonPressImpl and caused the popup, which doesn't return until the menu goes away, and second it goes down eventEmitter.emitButtonPress...but the widget and its emitter are gone.
So I threw timeout at it and made copies of things in popup_*.
OK, committed with some minor changes and comments. Please check. After reading the patch, it seems the timeout helps to get rid of the events that popped it up, so they're not obsolete after a page change. This avoids the segfault, and also cuts the execute on button-release feature. I wondered what was the "FLTK-way" of doing it, and experimented a bit, but after finding this warning, I decided to commit: Menu_popup.cxx: // Implementation of popup menus. These are called by using the // Menu::popup and Menu::pulldown methods. See also the // Menu base class in Menu.cxx. Warning: this code is // quite a mess! Also, the classes defined here are private and // may change in the future! :-) BTW, It looks as though FLTK-1.3 may be a good option after all... -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de