Closed Bug 504425 Opened 15 years ago Closed 15 years ago

Pages with no <title> look odd in new autocomplete window

Categories

(Camino Graveyard :: Location Bar & Autocomplete, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Camino2.1

People

(Reporter: alqahira, Assigned: dan.j.weber)

References

()

Details

(Keywords: polish)

Attachments

(1 file, 1 obsolete file)

986 bytes, patch
stuart.morgan+bugzilla
: review+
mikepinkerton
: superreview+
Details | Diff | Splinter Review
Previously, pages with no <title> looked like

[icon] http://page.with.no/title                           
[icon] http://page.with.com/title           My Awesome Page

i.e., a blank "title" column, which was OK since the leftmost column, where your eyes is drawn, was always populated and contained the important info.

In the new world, pages with no <title> look like

[icon]                                      http://page.with.no/title
[icon] My Awesome Page                      http://page.with.com/title

looks bad and is confusing, since the leftmost column containing the important info is now blank.

We should do something for these pages; suggestions include:

1) Safari apparently uses "(no title)"
2) We could put the full URL, like we do in the titlebar for these pages
3) We could just list the domain, "since it's the part users are most likely to know/understand"
Attached patch Patch 1 (obsolete) — Splinter Review
This sets blank titles to the host. I think this makes the most sense out of the options so far because setting the title to the entire URL is just repeating information that is right there.
Attachment #389183 - Flags: review?(stuart.morgan+bugzilla)
Assignee: nobody → dan.j.weber
Status: NEW → ASSIGNED
Comment on attachment 389183 [details] [diff] [review]
Patch 1

>+    [info setTitle:[[NSURL URLWithString:[info url]] host]];

This will work in most cases, but not all; we've run into cases where bookmarks aren't actually NSURL-able; for example, bookmarklets, which have javascript:<a lot of javascript> sometimes aren't properly escaped, so URLWithString will give you nil. You'll need fallback logic to handle the nil case--probably just put the URL when that happens.
Attachment #389183 - Flags: review?(stuart.morgan+bugzilla) → review-
Attached patch Patch 2Splinter Review
Attachment #389183 - Attachment is obsolete: true
Attachment #389241 - Flags: review?(stuart.morgan+bugzilla)
Attachment #389241 - Flags: superreview?(mikepinkerton)
Attachment #389241 - Flags: review?(stuart.morgan+bugzilla)
Attachment #389241 - Flags: review+
Comment on attachment 389241 [details] [diff] [review]
Patch 2

>+    if (host)
>+      [info setTitle:host];
>+    else
>+      [info setTitle:[info url]];

Maybe more readable as just
  [info setTitle:(host ? host : [info url])];
? Your call though.
Comment on attachment 389241 [details] [diff] [review]
Patch 2

sr=pink
Attachment #389241 - Flags: superreview?(mikepinkerton) → superreview+
Checked in on cvs trunk with
 [info setTitle:(host ? host : [info url])];
per dan on irc.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Moving these bugs to the 2.1 milestone to make it easier for them to fall out of the rough "all bugs fixed for 2.0" query.
Target Milestone: --- → Camino2.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: