Bug 41451 - [Qt] Crash when destroying a QWebView with a QComboBox as its child.
Summary: [Qt] Crash when destroying a QWebView with a QComboBox as its child.
Status: CLOSED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Critical
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks: 35784
  Show dependency treegraph
 
Reported: 2010-07-01 03:11 PDT by Jocelyn Turcotte
Modified: 2010-07-01 12:52 PDT (History)
2 users (show)

See Also:


Attachments
Patch (5.20 KB, patch)
2010-07-01 03:49 PDT, Jocelyn Turcotte
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jocelyn Turcotte 2010-07-01 03:11:56 PDT
To reproduce:
- Open a page with combo boxes and click one of them (like http://www.google.com/advanced_search )
- Get the QWebView destroyed (either by closing the tab in Arora or by switching to graphics web view in QtTestBrowser)
- Wander around browsing waiting for the cache to get cleaned (might take something between 1 and 5 minutes)

What happens is that when we show the combo box popup, we set the QWebView as the QComboBox parent.
If the QComboBox gets destroyed because of its parent getting destroyed, the reference in the render tree become dangling.
Comment 1 Jocelyn Turcotte 2010-07-01 03:49:50 PDT
Created attachment 60220 [details]
Patch
Comment 2 WebKit Commit Bot 2010-07-01 05:17:24 PDT
Comment on attachment 60220 [details]
Patch

Clearing flags on attachment: 60220

Committed r62251: <http://trac.webkit.org/changeset/62251>
Comment 3 WebKit Commit Bot 2010-07-01 05:17:29 PDT
All reviewed patches have been landed.  Closing bug.
Comment 4 Simon Hausmann 2010-07-01 12:52:20 PDT
Revision r62251 cherry-picked into qtwebkit-2.0 with commit ed5e839ffbd751c0a39de712f0b37c91e6e5dcc7