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

RESOLVED FIXED in Camino2.1

Status

Camino Graveyard
Location Bar & Autocomplete
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Assigned: Dan Weber)

Tracking

({polish})

Trunk
Camino2.1
All
Mac OS X
polish
Dependency tree / graph

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

986 bytes, patch
Stuart Morgan
: review+
Mike Pinkerton (not reading bugmail)
: 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"
(Assignee)

Comment 1

9 years ago
Created attachment 389183 [details] [diff] [review]
Patch 1

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 2

9 years ago
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-
(Assignee)

Comment 3

9 years ago
Created attachment 389241 [details] [diff] [review]
Patch 2
Attachment #389183 - Attachment is obsolete: true
Attachment #389241 - Flags: review?(stuart.morgan+bugzilla)

Updated

9 years ago
Attachment #389241 - Flags: superreview?(mikepinkerton)
Attachment #389241 - Flags: review?(stuart.morgan+bugzilla)
Attachment #389241 - Flags: review+

Comment 4

9 years ago
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
Last Resolved: 9 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.