363633 - Use file proxy in window titlebar when viewing local files (cmd-click to show path)

Status: RESOLVED WONTFIX

(Camino Graveyard :: OS Integration, defect)

Description

[froodian (Ian Leue)]

This is like bug 175470, but for files (cmd-click in titlebar should display file path, dragging titlebar icon should work as proxy).  While bug 175470 is slightly controversial, we should absolutely do this for files for consistency with the rest of of the OS.  I could have sworn this was filed, but I couldn't find it...

Comment 1

[froodian (Ian Leue)]

Attachment: Patch

Comment 2

[froodian (Ian Leue)]

Attachment: Patch

Per IRC, doing a variable name change and commenting to make it clear why we're setting the path to @"" in the nil case.

Comment 3

[Wevah (Nate Weaver)]

Comment on attachment 248437 [details] [diff] [review]
Patch

codewise r=me

Comment 4

[froodian (Ian Leue)]

Comment on attachment 248437 [details] [diff] [review]
Patch

This is all fine and well for when we just load a new page, but it won't persist across tab changes.

Comment 5

[froodian (Ian Leue)]

Attachment: Patch

Now with 70% less wrongness.

Comment 6

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

(In reply to comment #0)
> I could have sworn this was filed, but I couldn't find it...
 
Maybe you were thinking of the related bug 346228?

Comment 7

[froodian (Ian Leue)]

Attachment: Patch

Per IRC, no point in keeping anything we don't really need in memory.  Instead, this just grabs the URL and calculates the path from it each time we change the window title.  It also changes the paradigm slightly (by giving |updateWindowTitle| no arguments) so that updateWindowTitle can pull all of its information, rather than being given the title and pulling the path...

Which has the added bonus of making bug 309874 easy to fix.  This always truncates the title to 80 chars if on 10.3 or previous, and lets the OS truncate the title gracefully if we're on 10.4 or higher.

Comment 8

[Wevah (Nate Weaver)]

Comment on attachment 248451 [details] [diff] [review]
Patch

codewise r=me; I think I like this one.

Comment 9

[Stuart Morgan]

Comment on attachment 248451 [details] [diff] [review]
Patch

We need to discuss whether we want this before it's sr'd. It creates a significant inconsistency between the appearance and behavior of the title bar for local files vs. web pages. Right now we always have a favicon in the tabs, and it does a reasonable thing for whatever it represents. Having a favicon in the title bar only sometimes doesn't really seem like a good idea to me, since it's not the way we do things anywhere else. I think we need to do the same thing here in all cases.

There's also the question of how many places we want the favicon showing up. Having it in the URL bar then again right above it in the title bar seems a bit weird.

Comment 10

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

My 2¢ wrt this is that internal consistency here is more important than acting 100% like a document-based Cocoa app.  So I'm happy to forgo the icon in the titlebar, but I think we should keep the menu since we do plan (last I checked) to add that for sites as well.

Comment 11

[froodian (Ian Leue)]

WONTFIX in favor of bug 364198.