Closed Bug 309874 Opened 19 years ago Closed 17 years ago

When page with long title is displayed, window title is poorly truncated

Categories

(Camino Graveyard :: General, defect)

PowerPC
macOS
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED
Camino1.5

People

(Reporter: sugar.waffle, Assigned: froodian)

References

()

Details

(Keywords: fixed1.8.1.2, polish)

Attachments

(8 files, 2 obsolete files)

When the page of a long title in Safari and Firefox is displayed, it is omitted
on the way of the title according to the width of the window. 
However, it is not so in Camino. 

I think that it should display the title as much as Safari or Firefox. 

Reproducible: Always

Steps to Reproduce:
1.Open URL
2. See title of browser window

Mac OS X 10.3.9
trunk build 2005092412 (v1.0+)
Attached image screen shot of Camino
Attached image screen shot of Safari
Attached image screen shot of Firefox
with 1.0a1, camino looks like firefox. what's changed here?
Summary: When the page of a long title is displayed, the display of the title of the window is bad. → When the page of a long title is displayed, the display of the title of the window is bad.
I don't see this in either my trunk or branch build from today.  10.4.2.

I notice that the ellipsis changes between the system font and the text font
depending on how much is being chopped off.  There may be two different
ellipsizers at work here, at least on 10.4.2, and that might not be the case on
10.3.9.
I've seen titles erroneously truncated (by an elipsis at the end!) when they're
not nearly long enough to need it, but I've never been able to relaibly
reproduce it or determine why some page loads cause it and not other loads of
the same page (10.3.9 here).

I see what crot0's screenshot shows on that URL, though...no elipsis and the
title running into the hide toolbar widget.
Does this only happen with non-Roman titles?
Summary: When the page of a long title is displayed, the display of the title of the window is bad. → When page with long title is displayed, window title is poorly truncated
(In reply to comment #4)
> with 1.0a1, camino looks like firefox. what's changed here?

It reproduces though 1.0a1 was tried. 
(In reply to comment #7)
> Does this only happen with non-Roman titles?

No, it happens with Roman titles, too (often alternatively with the
over-agressive truncation).

Roman testcase and screenshots coming.
Attached file Roman testcase
Here's a page with a very long Roman title.  It alternately a) is never
truncated and runs into the Hide Toolbar widget and b) is over-truncated (i.e.,
it could be longer before it is truncated).
The truncation can be overzealous on titles that aren't terribly long, either,
e.g., this bug.  There's clearly room for 5 more characters in my titlebar, so
no need for this title to be truncated.

I wonder if all of this is related to the changes in bug 294226 (the Window
menu can still stretch halfway across my screen when this bug's testcase is the
active tab and its title is displayed in the non-truncated state.  The Window
menu actually does internal truncation in that case, but it still stretches
halfway across my screen).
For whatever it's worth, using what basically matches the nightly from two days
ago (though it's a custom build with several patches applied), I only get the
overzealous truncation on the testcase.

The Japanese page in the bug's URL field gets truncated in a manner that appears
to be reasonable.

cl
Since you mentioned bug 294226, I thought I'd count...

It truncates at 80 characters in the testcase.

Now, here's the fun part.

It truncates at a reasonable width -- in my case, after the word 'testcase' --
*if I switch tabs and then switch back to the testcase*. If I resize the window
while the testcase is in the active tab, it re-truncates as necessary, and
appears to do so properly. If I resize the window while another tab is active,
upon switching to the testcase, it is properly truncated.

So it looks like the problem only happens on the initial page load, and only if
the page is loaded as the frontmost tab or window.

cl
One more comment (sorry for the bugspam):

If I load the testcase as the front-most tab, resizing has no effect until the
tab gets sent to the background. Upon switching back to the testcase, it's fixed.

cl
Wow, that's way more triaging than I expected!

The 80-character truncation limit comes from BrowserWrapper's
-setTabTitle:windowTitle:.  This is specific to Camino and always truncates at
the end with the "standard" … character.  This is what Smokey is calling
"over-truncation."  That's not the only place that setTitle is called on the
NSWindow, though.  BrowserWindowController's -updateFromFrontmostTab will also
call it without any truncation limit at all.  If Camino "over-truncates" a
title, switch tabs and you'll get the full text.

On 10.4.2, titles of Cocoa windows are intelligently truncated with an ellipsis
appropriate to the text that precedes it (so, not always …, hence the
Japanese ellipsis on Tiger in crot0's test), but on 10.3.9, the titles run
straight to the end and are cut off in a most unappealing display of ugliness. 
Try any other Cocoa app on 10.3.9, such as TextEdit.  There's really not much
that can be done about this.  Workarounds are kind of hacky.

The 80/no-limit discrepancy should be addressed.  Perhaps this should be made
conditional on OS release, so that Camino doesn't truncate internally on Tiger
where the system will make everything look pretty, and will always apply some
reasonable limit (like 80) pre-Tiger.
(In reply to comment #17)
> but on 10.3.9, the titles run
> straight to the end and are cut off in a most unappealing display of ugliness.

Interestingly, when I expanded my window width on the testcase to allow it to
display completely and then began dragging it smaller again, there *initially*
was a large grey patch between the text and the Hide Toolbar widget (some of the
title text simply disappeared, but there was decent padding so that no letters
were running into the widget).  As I continued to shrink back to my normal
window size, that padding disappeared.  (As you can see in attachment 197309 [details],
there's more grey on the left between the green globe and the text than there is
between the text and the hide toolbar widget--seems like the left-side padding
never gets abandoned, unlike the right side.  I'm assuming that's an OS bug.)

Is there no way on 10.3.x to intelligently truncate based on window width? 
Truncation at 80 characters looks really wierd on my setup on an 85-character
title (e.g., this bug).
not unless we start making assumptions about the location of buttons in the window titlebar and the system font size.
So this can only be fixed on 10.4. Changing summary to reflect that fact, depsite it occuring on other platforms.

As such, this isn't needed for 1.0, but can be part of our platform-specific changes in 1.1 (while we're dropping 10.2).
Summary: When page with long title is displayed, window title is poorly truncated → [10.4] When page with long title is displayed, window title is poorly truncated
Target Milestone: --- → Camino1.1
It's pretty trivial to get the frame rects of window frame buttons, FWIW.
There's a non-10.4 component that needs to be fixed here, too (the fact that titles can be truncated or run into the toolbar widget, i.e. the last pgh of Mark's comment 17), so I'm removing [10.4] from the summary.  Poor truncation happens on all OS versions, just differently.
Summary: [10.4] When page with long title is displayed, window title is poorly truncated → When page with long title is displayed, window title is poorly truncated
Assignee: mikepinkerton → nobody
Keywords: polish
QA Contact: general
Target Milestone: Camino1.1 → Camino1.2
Version: Trunk → unspecified
Assignee: nobody → stridey
Depends on: 363633
No longer depends on: 363633
Ian's going to fix the fact we can be non-truncated on 10.3.9 as part of bug 363633, and then here we'll work up better truncation for 10.3 (internal truncation, and get the width of the window and estimate the control size and truncate to that instead of always to 80) and whatever's needed for 10.4.
Attached patch Patch (obsolete) — Splinter Review
This is almost 100% sketch-free.  It makes assumptions about the amount of space in between title bar widgets, but does everything else intelligently.  Behaviorally, the change is that titles will truncate at all on 10.3, and will middle-truncate for everybody.
Attachment #250878 - Flags: review?(stuart.morgan)
Comment on attachment 250878 [details] [diff] [review]
Patch

This should use the frame information of those buttons, rather than the sizes plus hard-coded values.
Attachment #250878 - Flags: review?(stuart.morgan) → review-
Oh, and be sure to conditionalize computation involving the toolbar button in case we ever go back to a mode where it doesn't exist in all windows.
Attached patch Patch (obsolete) — Splinter Review
Addresses smorgan's review comments.  Also ups the padding surrounding the title (the only value still hardcoded now) to 8 px on each side, per some usability testing from ardissone where titles could still occasionally be cut off.
Attachment #250878 - Attachment is obsolete: true
Attachment #251706 - Flags: review?(stuart.morgan)
Comment on attachment 251706 [details] [diff] [review]
Patch

This works a lot better than the last one, and addresses all the issues I had with the last patch behavior-wise.
Attachment #251706 - Flags: review+
Comment on attachment 251706 [details] [diff] [review]
Patch

>+  // The title starts 8 pixels after the zoom widget ends
>+  float titleStart = zoomButtonFrame.origin.x + zoomButtonFrame.size.width + 8;

origin.x + size.width == NSMaxX(zoomButtonFrame)

>+  NSButton* toolbarButton = [window standardWindowButton:NSWindowToolbarButton];
>+  // If there's a toolbar widget, the title ends 8 pixels before it.  If not, 8 pixels before the edge of the window
>+  float titleEnd = toolbarButton ? ([toolbarButton frame].origin.x - 8) : ([window frame].size.width - 8);
>+  float titleWidth = titleEnd - titleStart;

Rather than have the padding repeated in the computation (and having the magic number in code), how about something like:
  float leftEdge = NSMaxX(zoomButtonFrame);
  ...
  float rightEdge = toolbarButton ? [toolbarButton frame].origin.x : NSMaxX([window frame]);
  // Leave 8 pixels of padding around the title.
  int padding = 8;
  float titleWidth = rightEdge - leftEdge - 2 * padding;

>+  // Sending |titleBarFontOfSize| 0 or a negative number returns default size

Get rid of the "or a negative number" since you aren't doing that.

r=me with those changes.
Attachment #251706 - Flags: review?(stuart.morgan) → review+
Attached patch r=smorgan patchSplinter Review
Carrying r+ from previous patch.
Attachment #251706 - Attachment is obsolete: true
Attachment #252662 - Flags: superreview?(mikepinkerton)
Attachment #252662 - Flags: review+
Comment on attachment 252662 [details] [diff] [review]
r=smorgan patch

+  // Leave 8 pixels of padding around the title.
+  int padding = 8;

if this is a constant, name it as such, and make it const. 

eg, const int kTitlePadding = 8;

sr=pink with that.
Attachment #252662 - Flags: superreview?(mikepinkerton) → superreview+
Checked in on trunk and MOZILLA_1_8_BRANCH with the above comment.
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8.1.2
Resolution: --- → FIXED
Moving fixed "1.2" bugs to 1.1 where they were really fixed. Filter on CaminoFixed1.1 for bugmail purposes.
Target Milestone: Camino1.2 → Camino1.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: