User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051020 Camino/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051020 Camino/1.0+ E.g., the .url file containing [InternetShortcut] URL=http://www.esm.psu.edu/mac-tex/ with UNIX newlines after the two lines using BBEdit; saved as MacOSXTeX.url. Double clicking (Camino is my default browser) or Drag&Drop onto Camino icon I get a new tab (preferences set to do that) that says loading... but nothing actually loads. Works fine Drag&Drop on Safari, etc. If I change the newlines to CRLF (DOS) it works properly. Reproducible: Always Steps to Reproduce: 1.Write the .url file with Unix newlines 2.Double Click (if Camino is default browser) or drop on Camino icon 3. Actual Results: Get the loading... message that never completes. Expected Results: Loaded the URL contained in .url file If you change the Unix newlines to CRLF (DOS) newlines the page loads properly.
Confirmed. This is Wevah's. There are a couple of other wrinkles, too (EOFs maybe?); I'll attach a problematic .url generated via AppleScript that other browsers parse fine but which causes the same "Loading..." condition in Camino.
Assignee: mikepinkerton → mozilla
Status: UNCONFIRMED → NEW
Ever confirmed: true
One never loads, the other loads the wrong page (an extra %0A shows in the location bar). Both load properly in Safari 1.3.1 and iCab 3.
FWIW, "Each line terminates with CR and LF characters [...]" (from http://www.cyanwerks.com/file-format-url.html) I'm going to post a patch for this, anyway. I think we should allow any of the three common line endings.
The "loads wrong URL" file has inconsistent line endings; the first line ends with CRLF, the second only ends with LF.
(In reply to comment #4) > The "loads wrong URL" file has inconsistent line endings; the first line ends > with CRLF, the second only ends with LF. Thanks; I've changed my script to work around whatever's inserting that rougue LF. I concur that we should support any of the three common schemes since 1) Safari does and 2) there are lots of (incorrect) code hints out there that are using only LF, apparently based on some guessing-work analysis of Safari behavior (my script's based on code samples from macosxhints.com).
Severity: normal → minor
This patch uses an NSScanner to grab the URL, and is line-ending agnostic. It will properly read the URL from both .url files in the ZIP archive attached to this bug.
Attachment #200463 - Flags: review?(sfraser_bugs)
Comment on attachment 200463 [details] [diff] [review] Patch. >Index: NSURL+Utils.m >=================================================================== >+ if ([scanner scanString:@"[InternetShortcut]" intoString:nil] && [scanner scanString:@"URL=" intoString:nil] && [scanner scanUpToCharactersFromSet:newlines intoString:&urlString]) >+ ret = [NSURL URLWithString:urlString]; Break the if test onto 3 lines, and r=sfraser
Attachment #200463 - Flags: review?(sfraser_bugs) → review+
Patch with multiline if statement (just to make things easier).
Attachment #200945 - Flags: review? → review?(sfraser_bugs)
Comment on attachment 200945 [details] [diff] [review] Patch take 2 I'd line up the "[scanner " on each line, but that's just me.
Attachment #200945 - Flags: review?(sfraser_bugs) → review+
It doesn't matter to me either way. I'll make a new patch if you want; otherwise I've no problem with whoever checks it in making the change.
landed on trunk and branch
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Camino1.0
You need to log in before you can comment on or make changes to this bug.