188043 - File-Open, drag to Dock icon/tab widget/content area does not open some types of weblocs

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect, P3)

Description

[Stephane Moureau]

If you drag an URL to the Finder, it creates a *.webloc file.
That file can not be opened from File-Open. It can be used via Finder-Open.
Allow File-Open to select *.webloc files.
Build 0101.

Comment 1

[saari (gone)]

->sfraser

Comment 2

[Mason Lee]

  I _think_ this bug might be related to the behavior I am seeing:
  I have assigned "hot keys" to a couple of my .webloc files using a utility
called MaxMenus.  With Chimera0.6.0, activating these hot keys would open the
browser to the web location specified in the file.  Since installing Camino,
however, activating these files via MaxMenus opens the browser to the file
itself (e.g. file://...) instead of the http location specified in the webloc file.
  (Interesting side note-- installing Camino broke the ability for me to open
these files in this manner in Chimera0.6.0 also.)
  Many thanks to whoever fixes this!  Cheers!

Comment 3

[Jasper]

This bug was fixed by the checkin of Bug 242934.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This bug is not fixed for two situations in 2005012108 (v0.8+):

1) Weblocs whose name end with /.webloc
2) Weblocs whose name does not contain .webloc (either {A} an old-style Mac OS
8/9 webloc [creator: drag] or {B} a modern webloc [creator: MACS] whose name has
been user-edited) 

Weblocs meeting condition 2) also are not fixed with reference to bug 242934
(i.e., the weblocs themselves are downloaded rather than Camino going to the
contained URLs).

Reopening (this one, because it's easier to describe the failing of both in this
bug than in the other bug).  I will attach a zip file containing a sample of
each of the three webloc types.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Zip file with weblocs of types 1, 2A, 2B in comment 4

Comment 6

[Jasper]

Updating symmary as it looked like it was fixed.

Note: I do think that requesting all these things to be fixed is a bit far
fetched as the chance of people having all the different kinds of funkyness is
pretty small. On the other hand safari does handle it the way described.

Comment 7

[Wevah (Nate Weaver)]

I'm doing a patch to allow Camino to handle .ftploc files; should I add a
type/creator check into that patch as well?

Comment 8

[Wevah (Nate Weaver)]

Oh, bug 289243 for the .ftploc stuff.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Variation on type 1 of comment 4, described in comment 9 (.html.webloc)

To address Jasper's comment, 90% of the nearly-1000 webloc files I have meet
conditions 1 or 2 and thus fail to work properly in Camino right now from File:
Open and/or from drag-drop onto the app/dock icon (bug 242934).  

If you're a recent switcher who's only ever used Safari or Camino and have
never edited names of weblocs you've created (and if the icon artists/sw
authors/etc. including weblocs in their distributions have done the same),
you're OK.  

If you're a long-time Mac user, or if you've used Firefox (which produces urls
of type 1 above), or you've edited the name in some way, your weblocs will work
in Camino hit-and-miss.  For consistency's sake/a good user experience, it
would be nice to fix these holes if it's not too difficult--and, as Japser
notes, Safari does handle all these cases properly.

As for ftplocs, I have 4 on my Mac.  Two predate Mac OS X, one ends in .ftploc,
and the fourth one I created yesterday and then renamed so I could tell *what*
it would take me to rather than an a confusing URL....

(I've also discovered a variation on type 1 of webloc, which fails File:Open
only: it ends in .html.webloc  Sample attached)

That said, I'm not sure this answers Wevah's question, if it was even addressed
to me....  Sorry for the rambling. :-(

Comment 10

[Wevah (Nate Weaver)]

I can fix most of these issues, I just want to know if I should roll it into my
.ftploc patch. ;)

Comment 11

[Wevah (Nate Weaver)]

(In reply to comment #4)
> 1) Weblocs whose name end with /.webloc

These WFM.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #11)
> (In reply to comment #4)
> > 1) Weblocs whose name end with /.webloc
> 
> These WFM.

I just went to http://www.mozilla.org/products/firefox/ in Firefox, dragged the
URL to the desktop, came back to Camino, and the new webloc is greyed out in
File:Open--as are about half of the weblocs on my desktop :-(

Comment 13

[Wevah (Nate Weaver)]

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #4)
> > > 1) Weblocs whose name end with /.webloc
> > 
> > These WFM.
> 
> I just went to http://www.mozilla.org/products/firefox/ in Firefox, dragged the
> URL to the desktop, came back to Camino, and the new webloc is greyed out in
> File:Open--as are about half of the weblocs on my desktop :-(

Oh crap, that's right; you're talking about File -> Open, not whether Camino can
open them at all.

I've decided: whether I roll this stuff into my other patch or not, I'll take
this, since I know how to fix the other (type/creator code-based) issues.

Comment 14

[Wevah (Nate Weaver)]

Ok, it looks like the issue for files named like "foo/.webloc" is an Apple bug
in the Open panel. As for files named "foo.html.webloc", we may be checking the
filename badly for File -> Open as opposed to drag and drop.

Comment 15

[Wevah (Nate Weaver)]

Found it:

[urlStringsArray addObject:[curURL path]];

We should only be adding just the path if the result is a file:// URL. Maybe we
should still use the URL's absoluteString even then.

Comment 16

[Wevah (Nate Weaver)]

(In reply to comment #15)
> Found it:
> 
> [urlStringsArray addObject:[curURL path]];
> 
> We should only be adding just the path if the result is a file:// URL. Maybe we
> should still use the URL's absoluteString even then.

Err, this is for something else. Still a problem, though.

Comment 17

[Samuel Sidler (old account; do not CC)]

Wevah: Status update?

Comment 18

[Samuel Sidler (old account; do not CC)]

Wevah? Can you get this soon for 1.0? Until then, I'm moving off the 1.0 list.

Comment 19

[Wevah (Nate Weaver)]

The last (third) patch on bug 289243 should fix this issue.

Comment 20

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Fixed by checkin for bug 289243.