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)
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+)
Comment 4•19 years ago
|
||
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•19 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•19 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
(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.
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).
Comment 14•19 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•19 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•19 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•19 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).
Comment 19•19 years ago
|
||
not unless we start making assumptions about the location of buttons in the window titlebar and the system font size.
Comment 20•19 years ago
|
||
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•19 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
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•18 years ago
|
||
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•17 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•17 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•17 years ago
|
||
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•17 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•17 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•17 years ago
|
||
Carrying r+ from previous patch.
Attachment #251706 -
Attachment is obsolete: true
Attachment #252662 -
Flags: superreview?(mikepinkerton)
Attachment #252662 -
Flags: review+
Comment 31•17 years ago
|
||
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•17 years ago
|
||
Checked in on trunk and MOZILLA_1_8_BRANCH with the above comment.
Comment 33•17 years ago
|
||
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.
Description
•