What I did: typed the http URL of an RSS or Atom format XML file. What I expected: WebKit to present the URL using the internal stylesheet. What happened: WebKit tried to access the URL, then the address field changed to the same URL with the feed prefix, then it refreshed again and then looped until either the window was closed or "Cmd + ." was pressed.
What happends if you try using "feeds://" instead of "feed://"? I'm not sure that's URL scheme is even supported, but I would expect it to be the SSL version of the "feed" scheme. If this bug is confirmed, it will likely be a bug in Safari or the network layer code, not WebKit itself. It would probably be a good idea to file a Radar bug using http://bugreport.apple.com/. If you do that, please note the bug number here and add the "InRadar" keyword to this bug. If you don't have an Apple Developer Connection (ADC) membership, you can sign up for a free "online" membership at http://connect.apple.com/.
(In reply to comment #0) > What I did: typed the http URL of an RSS or Atom format XML file. What blog URL did you use? I tried this one, but it doesn't appear there is an SSL site set up for this web server: https://houseofwarwick.blogspot.com/atom.xml
David: I don't know where you're getting the https from or even the issue about SSL. This bug has nothing to do with either. Did you read my original description? Have you tried taking the nightly build and entering *any* XML URL?
(In reply to comment #3) > David: > > I don't know where you're getting the https from or even the issue about SSL. > This bug has nothing to do with either. Did you read my original description? > Have you tried taking the nightly build and entering *any* XML URL? Sorry, I must have misread "RSS" as "SSL". :) This URL loads fine for me: http://houseofwarwick.blogspot.com/atom.xml Which nightly were you using? I tried r15015 and it worked fine. Do you have an "haxies" installed like PithHelmet or Saft? Those could affect Safari+WebKit's behavior quite a bit, although usually they cause crashes in nightly builds (because internal code that they rely on has changed).
(In reply to comment #4) > This URL loads fine for me: http://houseofwarwick.blogspot.com/atom.xml > Which nightly were you using? I tried r15015 and it worked fine. Make that r15105.
I also couldn't reproduce this with <http://houseofwarwick.blogspot.com/atom.xml>. One additional thing to check: what are the settings for the default Web browser and RSS reader in your Safari preferences?
Created attachment 9105 [details] Movie that shows odd refresh loop
All: I'm using the nightly builds--not sure of the revision number of source--and the version I'm using today is the "Friday June 30" build. I can build from source if needed. RE: prefs--My Safari and Webkit prefs are WebKit for default browser and WebKit for default RSS reader. In addition, I deleted the user prefs (in ~/Library/Preferences) and the issue remained. I'm uploading a movie of the behavior. I'm open to options on testing.
Steve, at this point, it may be helpful to get a packet trace of what's happening with a tool like Ethereal or tcpdump. BTW, is this feed bookmarked? That may be one major difference is that I don't have this feed bookmarked.
I did a quick tcpdump while accessing the URL http://houseofwarwick.blogspot.com/atom.xml and the results were as expected. WebKit receives the file but is failing when it tries to parse the file and show the results via internal stylesheet. If I was guessing, I'd say something is broken on the XSLT side. My config: iBook G3/700 640MB of RAM 20GB HD MacOS X 10.4.7 Are the people that are having success on PPC or Intel Macs? tcpdump below: brubeck:~ steve$ sudo tcpdump -i en1 host brubeck.local>>tcp.txt tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en1, link-type EN10MB (Ethernet), capture size 96 bytes ^C19 packets captured 25 packets received by filter 0 packets dropped by kernel brubeck:~ steve$ more tcp.txt 10:58:59.546454 IP 192.168.0.4.52098 > 66.102.15.101.http: S 2941516678:2941516678(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,times tamp 898725404 0> 10:58:59.627850 IP 66.102.15.101.http > 192.168.0.4.52098: S 1412701066:1412701066(0) ack 2941516679 win 8190 <mss 1460> 10:58:59.628129 IP 192.168.0.4.52098 > 66.102.15.101.http: . ack 1 win 65535 10:58:59.629373 IP 192.168.0.4.52098 > 66.102.15.101.http: P 1:260(259) ack 1 win 65535 10:58:59.715205 IP 66.102.15.101.http > 192.168.0.4.52098: . ack 260 win 6432 10:58:59.725651 IP 66.102.15.101.http > 192.168.0.4.52098: . 1:1461(1460) ack 260 win 6432 10:58:59.731254 IP 66.102.15.101.http > 192.168.0.4.52098: . 1461:2921(1460) ack 260 win 6432 10:58:59.731430 IP 192.168.0.4.52098 > 66.102.15.101.http: . ack 2921 win 64240 10:58:59.741179 IP 192.168.0.4.52098 > 66.102.15.101.http: F 260:260(0) ack 2921 win 65535 10:58:59.819642 IP 66.102.15.101.http > 192.168.0.4.52098: . 2921:4381(1460) ack 260 win 6432 10:58:59.819857 IP 192.168.0.4.52098 > 66.102.15.101.http: R 2941516938:2941516938(0) win 0 10:58:59.822720 IP 66.102.15.101.http > 192.168.0.4.52098: . 4381:5841(1460) ack 260 win 6432 10:58:59.822807 IP 192.168.0.4.52098 > 66.102.15.101.http: R 2941516938:2941516938(0) win 0 10:58:59.825221 IP 66.102.15.101.http > 192.168.0.4.52098: . 5841:7301(1460) ack 260 win 6432 10:58:59.825322 IP 192.168.0.4.52098 > 66.102.15.101.http: R 2941516938:2941516938(0) win 0 10:59:00.174879 IP 192.168.0.4.51892 > ns1.mchsi.com.domain: 15860+ PTR? 101.15.102.66.in-addr.arpa. (44) 10:59:00.229376 IP ns1.mchsi.com.domain > 192.168.0.4.51892: 15860 NXDomain 0/1/0 (104) 10:59:00.262313 IP 66.102.15.101.http > 192.168.0.4.52098: . 2921:4381(1460) ack 261 win 6432 10:59:00.262461 IP 192.168.0.4.52098 > 66.102.15.101.http: R 2941516939:2941516939(0) win 0 brubeck:~ steve$
I could try to attach a debugger to the app before I access the URL. I'm comfortable taking instructions from someone if needed, otherwise I'll stumble through the Xcode app until I find a way to record the info.
As a start, you can try logging the loading progress: - build WebKit from sources; - "defaults write com.apple.Safari WebKitLogLevel 0xffffffff" in Terminal; - Tools/Scripts/run-safari - defaults delete com.apple.Safari WebKitLogLevel Debugging may be tricky because RSS handling is not in WebKit; I'd start with setting a breakpoint in [WebLoader loadWithRequest:]. Also, please answer my question about Safari preferences from comment 6.
RE: prefs I answered those questions in comment 8. RE: bookmarked (from comment 9) No. Pick any XML URL and type it by hand and you'll see the same result. All: I'm getting ready to install the newest nightly build. Back in a sec.
Sorry, I don't know how I could overlook your reply :(. Yes, setting the default RSS reader to WebKit causes this behavior. To work around this, please set it back to Safari (feeds opened from WebKit will still be handled by WebKit). I couldn't reproduce this problem with non-feed XMLs.
After a bit of investigation it seems that the problem is caused by Safari detecting that the default feed reader is someone other than com.apple.Safari, and doing the equivalent of "open -b org.webkit.nightly.WebKit feed://houseofwarwick.blogspot.com". This then leads into a nice loop of WebKit opening the same URL, finding the feed handler is an external application, and trying to open it again. It looks as though Safari's -[RSSPreferences SafariIsNotDefaultFeedURLHandler] is responsible for the decision as to whether to handle the feed:// URL internally or via LaunchServices. I will provide a patch shortly which removes the ability for WebKit to be set as the default RSS reader. Users should instead set Safari as the default reader. As Alexey mentions this will lead to the feeds being handled internally when accessed from within WebKit. It does have the undesired effect of spawning Safari rather than WebKit when feeds are opened from outside of the web browser.
Created attachment 9145 [details] Don't claim to handle feed:// URLs in WebKit.app
Comment on attachment 9145 [details] Don't claim to handle feed:// URLs in WebKit.app r=me
Committed revision 15137.