Created attachment 354096 [details] screen shot of problem The folder properties dialog for local folders is drawn improperly; the rounded corners on the Retention Policy tab do not show. See the screen shot. To duplicate: right click on Local Folders -> Inbox and select Properties. Using 3.0b1 on Mac OS X Intel. Sorry if this is a dupe; I searched but did not find anything similar.
Markus: thoughts? It's http://mxr.mozilla.org/comm-central/source/mailnews/base/resources/content/folderProps.xul#66 where http://mxr.mozilla.org/comm-central/source/mailnews/base/resources/content/folderProps.js#273 sets .hidden on things including the last tab onload.
Version: unspecified → Trunk
Though even if we work around it in that dialog, there's still who knows how many extensions doing it (Enigmail was the one I saw a screenshot of this morning), and I don't think we want the solution to be an MDC paragraph saying "even though it looks like it works just fine to set a <tab> to .hidden, don't do it, because it looks like crap on OS X."
Assignee: nobody → joshmoz
Severity: trivial → normal
Component: Mail Window Front End → Widget: Cocoa
Product: Thunderbird → Core
QA Contact: front-end → cocoa
Summary: improperly drawn tabs in folder properties dialog for local folders → Newly modernized tabs look cut off if the last one is hidden
The appearance of the tabs is based on the presence of the "first-tab" / "last-tab" attributes. So we should probably update them whenever .hidden changes.
Status: NEW → ASSIGNED
Created attachment 354569 [details] [diff] [review] tabbox.xml approach, v1 This patch implements what I outlined in the previous comment.
Comment on attachment 354569 [details] [diff] [review] tabbox.xml approach, v1 >+ this.setAttribute("hidden", val ? "true" : "false"); Setting .hidden = false should remove the attribute.
Also, this won't work for .setAttribute("hidden", "true") or using display:none directly. This could probably be fixed by calling updateVisibilityFlags from the tab constructor and destructor. Or is there away to fix this on the widget level so that the first/last-tab attributes aren't needed at all?
Created attachment 354608 [details] [diff] [review] nsNativeTheme approach, v1 > Or is there away to fix this on the widget > level so that the first/last-tab attributes aren't needed at all? Yeah, and that's even easier. The only disadvantage of this approach is that theme developers who style the tabs with CSS don't benefit from it.
Attachment #354608 - Flags: review?(roc) → review+
Comment on attachment 354608 [details] [diff] [review] nsNativeTheme approach, v1 >+ nsIFrame* first = aFrame->GetParent()->GetFirstChild(NULL); Argument to GetFirstChild should be nsnull.
Attachment #354608 - Flags: superreview?(roc) → superreview+
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Landed on 1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/50b1f7631625
We don't have a possibility to test this automatically, right? Can we get a simple testcase which shows the broken behavior? It would be nice to have it in Litmus at least.
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
It's possible to write a reftest for this. I'll make one.
Created attachment 355221 [details] [diff] [review] reftest
Attachment #355221 - Flags: review?(roc)
Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090103 Shredder/3.0b2pre ID:20090103025757
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Attachment #355221 - Flags: review?(roc) → review+
Checked in the reftest on both mozilla-central and mozilla-1.9.1.
You need to log in before you can comment on or make changes to this bug.