Bug 67234 - REGRESSION(r93902): Can't open external links on gmail
Summary: REGRESSION(r93902): Can't open external links on gmail
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P1 Normal
Assignee: Alice Liu
URL:
Keywords: InRadar, Regression
: 67333 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-08-30 14:40 PDT by Ryosuke Niwa
Modified: 2011-09-01 06:43 PDT (History)
6 users (show)

See Also:


Attachments
Patch (3.69 KB, patch)
2011-08-31 14:34 PDT, Anders Carlsson
ap: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-08-30 14:40:22 PDT
Reproduction steps:
1. Go to gmail.com
2. Open some message that contains an external hyperlink
3. Open it while pressing the command key

Expected result:
The destination is opened in new tab

Actual result:
I get an alert with message "Grrr! A popup blocker may be preventing the application from opening the page. If you have a popup blocker, try disabling it to open the window."
Comment 1 Ryosuke Niwa 2011-08-30 14:43:04 PDT
Oops, this bug doesn't reproduce on released version of Safari 5.1.  Only on ToT.
Comment 2 Ryosuke Niwa 2011-08-30 16:25:33 PDT
r92990: good
r93707: good
r93849: good
r93903: bad
r93948: bad
Comment 3 Alexey Proskuryakov 2011-08-31 10:31:44 PDT
Further bisected to r93900-r93903, meaning that it's <http://trac.webkit.org/changeset/93902> (bug 66823).
Comment 4 Alexey Proskuryakov 2011-08-31 10:34:50 PDT
My steps to reproduce:
1. Open a webkit-changes list message in GMail.
2. Click or Cmd-click on revision number.

Expected results: changeset opens in a new window or tab.
Actual results: a "Grrr!" alert.
Comment 5 Alexey Proskuryakov 2011-08-31 10:35:06 PDT
<rdar://problem/10053636>
Comment 6 Ryosuke Niwa 2011-08-31 10:37:00 PDT
This might be also related to nightly not auto-installing new binaries.
Comment 7 Alice Liu 2011-08-31 11:19:59 PDT
looking now.
Comment 8 Alice Liu 2011-08-31 12:42:41 PDT
the window isn't created because sendSync returns false.  Looking further, sendSync does send the message okay, but it's having trouble decoding the reply. 

CoreIPC::ArgumentDecoder::markInvalid() at /Volumes/Data/Source/OpenSource/Source/WebKit2/Platform/CoreIPC/ArgumentDecoder.h:48
CoreIPC::ArgumentDecoder::alignBufferPosition(unsigned int, unsigned long) ()
CoreIPC::ArgumentDecoder::decodeUInt64 at /Volumes/Data/Source/OpenSource/Source/WebKit2/Platform/CoreIPC/ArgumentDecoder.cpp:156
CoreIPC::ArgumentDecoder::decode<unsigned long long> at /Volumes/Data/Source/OpenSource/Source/WebKit2/Platform/CoreIPC/ArgumentDecoder.h:136
CoreIPC::Arguments1<unsigned long long&>::decode at /Volumes/Data/Source/OpenSource/Source/WebKit2/Platform/CoreIPC/Arguments.h:77
CoreIPC::Arguments2<unsigned long long&, WebKit::WebPageCreationParameters&>::decode at /Volumes/Data/Source/OpenSource/Source/WebKit2/Platform/CoreIPC/Arguments.h:115
CoreIPC::ArgumentCoder<CoreIPC::Arguments2<unsigned long long&, WebKit::WebPageCreationParameters&> >::decode at /Volumes/Data/Source/OpenSource/Source/WebKit2/Platform/CoreIPC/ArgumentCoder.h:44
CoreIPC::ArgumentDecoder::decode<CoreIPC::Arguments2<unsigned long long&, WebKit::WebPageCreationParameters&> > at /Volumes/Data/Source/OpenSource/Source/WebKit2/Platform/CoreIPC/ArgumentDecoder.h:89
CoreIPC::Connection::sendSync<Messages::WebPageProxy::CreateNewPage> at /Volumes/Data/Source/OpenSource/Source/WebKit2/Platform/CoreIPC/Connection.h:386
WebKit::WebChromeClient::createWindow at /Volumes/Data/Source/OpenSource/Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:167
Comment 9 Anders Carlsson 2011-08-31 14:34:54 PDT
Created attachment 105828 [details]
Patch
Comment 10 Alexey Proskuryakov 2011-08-31 14:41:33 PDT
Comment on attachment 105828 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=105828&action=review

This bug couldn't happen on Windows, could it?

> Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:521
> +    // FIXME: Move this to ArgumentCodersCFMac.mm and change this file back to be C++

Is there a reason why this cannot be done right away? Leaving ArgumentCodersCF.cpp in Objective C++ mode seems unfortunate.

> Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:525
> +        result = reinterpret_cast<CFURLRef>([NSURL URLWithString:@""]);

Would be nice to avoid leaving an autoreleased object behind - NSURL has initWithString:.
Comment 11 Anders Carlsson 2011-08-31 16:14:48 PDT
(In reply to comment #10)
> (From update of attachment 105828 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=105828&action=review
> 
> This bug couldn't happen on Windows, could it?
> 

Not sure...

> > Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:521
> > +    // FIXME: Move this to ArgumentCodersCFMac.mm and change this file back to be C++
> 
> Is there a reason why this cannot be done right away? Leaving ArgumentCodersCF.cpp in Objective C++ mode seems unfortunate.

I wanted to get this fix landed as soon as possible.

> 
> > Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:525
> > +        result = reinterpret_cast<CFURLRef>([NSURL URLWithString:@""]);
> 
> Would be nice to avoid leaving an autoreleased object behind - NSURL has initWithString:.

I couldn't find an elegant way to do that given that we want to call adoptNS on a RetainPtr<CFURLRef>.
Comment 12 Anders Carlsson 2011-08-31 16:15:23 PDT
Committed r94246: <http://trac.webkit.org/changeset/94246>
Comment 13 Alexey Proskuryakov 2011-08-31 23:00:10 PDT
*** Bug 67333 has been marked as a duplicate of this bug. ***
Comment 14 Adam Roben (:aroben) 2011-09-01 06:43:44 PDT
Is it possible to write a test for this?