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.-