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

RESOLVED FIXED in Camino1.5

Status

--
minor
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: sugar.waffle, Assigned: froodian)

Tracking

({fixed1.8.1.2, polish})

unspecified
Camino1.5
PowerPC
Mac OS X
fixed1.8.1.2, polish

Details

(URL)

Attachments

(8 attachments, 2 obsolete attachments)

(Reporter)

Description

13 years ago
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+)
(Reporter)

Comment 1

13 years ago
Created attachment 197262 [details]
screen shot of Camino
(Reporter)

Comment 2

13 years ago
Created attachment 197263 [details]
screen shot of Safari
(Reporter)

Comment 3

13 years ago
Created attachment 197264 [details]
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.

Comment 5

13 years ago
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.

Comment 7

13 years ago
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
(Reporter)

Comment 8

13 years ago
(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.
Created attachment 197308 [details]
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).
Created attachment 197309 [details]
Screenshot of testcase in the non-truncated state
Created attachment 197310 [details]
Screenshot of testcase in the truncated/over-truncated state
Created attachment 197311 [details]
This bug, overzealously 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).

Comment 14

13 years ago
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

Comment 15

13 years ago
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

Comment 16

13 years ago
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

Comment 17

13 years ago
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

Comment 21

13 years ago
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)

Updated

12 years ago
Assignee: nobody → stridey
Depends on: 363633
(Assignee)

Updated

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

Comment 24

12 years ago
Created attachment 250878 [details] [diff] [review]
Patch

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 25

12 years ago
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-

Comment 26

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

Comment 27

12 years ago
Created attachment 251706 [details] [diff] [review]
Patch

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
(Assignee)

Updated

12 years ago
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 29

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

Comment 30

12 years ago
Created attachment 252662 [details] [diff] [review]
r=smorgan patch

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+
(Assignee)

Comment 32

12 years ago
Checked in on trunk and MOZILLA_1_8_BRANCH with the above comment.
Status: NEW → RESOLVED
Last Resolved: 12 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.