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."
Oops, this bug doesn't reproduce on released version of Safari 5.1. Only on ToT.
r92990: good r93707: good r93849: good r93903: bad r93948: bad
Further bisected to r93900-r93903, meaning that it's <http://trac.webkit.org/changeset/93902> (bug 66823).
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.
<rdar://problem/10053636>
This might be also related to nightly not auto-installing new binaries.
looking now.
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
Created attachment 105828 [details] Patch
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:.
(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>.
Committed r94246: <http://trac.webkit.org/changeset/94246>
*** Bug 67333 has been marked as a duplicate of this bug. ***
Is it possible to write a test for this?