Summary: | Chrome/mac crashes when opening a popup, waiting until the webpage in the background switches, and then clicking the popup | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Nico Weber <thakis> | ||||||
Component: | WebKit API | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | fishd, mark | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | PC | ||||||||
OS: | OS X 10.5 | ||||||||
Attachments: |
|
Description
Nico Weber
2009-11-17 17:34:28 PST
Created attachment 43394 [details]
Patch.
Comment on attachment 43394 [details] Patch. > Index: WebCore/platform/chromium/PopupMenuChromium.cpp ... > + // The popup sends its "closed" notification through its parentx Set the ^^^ typo > + // parent, even though external popups have no real on-screen widget but a > + // native menu (see |PopupListBox::hidePopup()|); > + if (!m_listBox->parent()) > + addChild(m_listBox.get()); Why would m_listBox's parent not be null? R- for the typo Created attachment 43401 [details]
Fix type
Heh, typo in "Fix typo". Nice.
> Why would m_listBox's parent not be null?
I was surprised too, but the branch for regular popups (PopupContainer::showPopup()) checks this too. So I figured it's safer to check this here as well.
Landed as http://trac.webkit.org/changeset/51102 I'm working off a tree from yesterday and I just wound up having to make this change to fix http://crbug.com/27723. Then I went to merge my work into WebKit so I could get it landed here and I got a merge conflict because you already hit this. Excellent! (Yeah, this is the correct fix.) |