If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Lightning does not play well with Personas (text-shadow and background issues)

RESOLVED FIXED in Thunderbird 3.3a1

Status

Thunderbird
Mail Window Front End
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: protz, Assigned: andreasn)

Tracking

unspecified
Thunderbird 3.3a1

Thunderbird Tracking Flags

(thunderbird3.1 .5-fixed)

Details

(Whiteboard: [good first bug])

Attachments

(6 attachments)

(Reporter)

Description

7 years ago
Lightning is too sensitive to styles applied by personas. There was a recent bug that fixed text-shadow being applied to mail headers by some personas in Thunderbird. It looks like it's the same issue here (see attached screenshot) for events.

Other issues include #today-pane-panel having background color set to -moz-dialog in chrome://calendar/skin/today-pane.css -- just setting it to transparent fixes the issue perfectly.
(Reporter)

Comment 1

7 years ago
Created attachment 452847 [details]
Screenshot of the issue.

Comment 2

7 years ago
Please be more specific. What Lightning version do you use? What Thunderbird bug are you referring to? What is the issue with Today Pane? (The background color has been added with Bug 539512 to fix a Personas issue) How can the bug be reproduced? Is there a specific Personas theme that can be used? What is wrong in the attached screenshot? ...
(Reporter)

Comment 3

7 years ago
bug 572084 enforces "no text-shadow in the message header". This should be enforced in events too. If you see no issue in the screenshot above, I do: the text is barely readable.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
Lightning 1.0b2rc3

The issue with the background color is that I'd rather have a transparent background for today pane than the default -moz-dialog background. It's a little bit weird to have the whole mail window themed with a personas while the today pane refuses to be themed.

The personas I'm talking about is "Firefox Pipes".

Updated

7 years ago
Duplicate of this bug: 583088
It is even worse with some other personas, e.g. IceAge. Personas is probably going to become more prominent in TB 3.2...
Flags: blocking-calendar1.0?

Comment 6

7 years ago
I have exactly the same problem but on windows 32-bit xp, go see the Bug 576271  I wrote. I have several catches showing also. Fortunately the Thunderbird interface corrected this problem in some detail. The wave more Lightning now.
We should try to fix this for the next beta, this is probably low hanging fruit.
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact][good first bug]
Created attachment 467733 [details]
Screenshot - v2

Suggestion for a fix. We don't want to make the whole Today Pane transparent, and just making the header transparent gives me the feeling that the sidebar header losses its connection with the today pane.

Therefore we could show a top border when -moz-lwtheme is enabled. This screenshot also gets rid of some margins so that the today pane elements look the same size.

I don't have the patch for this, its only quick hacked with DOM Inspector. I'd appreciate if someone could put together a patch for this if it gets ui-r+
Attachment #467733 - Flags: ui-review?(clarkbw)
(Assignee)

Updated

7 years ago
Attachment #467733 - Flags: ui-review?(clarkbw) → ui-review?(nisses.mail)
(Assignee)

Comment 9

7 years ago
"Stealing" this UI review from Bryan
(Assignee)

Comment 10

7 years ago
Comment on attachment 467733 [details]
Screenshot - v2

Looks great. Lets do that!
Attachment #467733 - Flags: ui-review?(nisses.mail) → ui-review+
Merike, since you already have some code, do you want to create a patch for this?
Yes, I can do that.

Need a hint though: how did you make the area between miniday and new event button transparent without making splitter between events and tasks transparent too? I can either make both transparent or neither of them but can't figure out a third way as both are contained in the same parent element and there seems to be no way to set splitter background separately..
I must admit I cheated on that! I couldn't find an obvious way of doing that and gimp helped me make it look that way ;-) Maybe someone from #developers/#extdev knows?

If all fails, we can probably just leave the splitter transparent.
Assignee: nobody → gasell+mozilla
Status: NEW → ASSIGNED
Splitters are tricky. I didn't find a way to make that splitter both solid color and keep the grippy visible. If -moz-appearance is set to none then color can be applied but the splitter behaviour is lost. If grippy is added (it's not there in DOM atm) then behaviour recovers (different cursor on hover and working drag) but grippy is invisible making it look different than other splitters in view.

So, which is better: having a solid color splitter without visible grippy or transparent splitter with normal grippy? Opinions welcome as I'm unable to decide, don't like neither of them much.
I was told KaiRo and Neil we're talking about this w.r.t Seamonkey and they felt that (at least regarding the Splitter between Content and Sidebar) it should stay opaque.

Since this is a horizontal splitter inside the "sidebar", I guess it could be slightly different, but if I'd have to pick, think I'd keep an opaque splitter too. What we could do to hack around the grippy image not being shown is to use an image background with the grippy. What OS are you working on?

We should file/find a toolkit bug to fix the splitter though.
(In reply to comment #15)
> I was told KaiRo and Neil we're talking about this w.r.t Seamonkey and they
> felt that (at least regarding the Splitter between Content and Sidebar) it
> should stay opaque.
This one, definitely. That's also what Firefox does with bookmarks and history. Actually copying exactly what Firefox does which is to make only sidebar title box transparent would be the easiest to do css and toolkit wise.

> Since this is a horizontal splitter inside the "sidebar", I guess it could be
> slightly different, but if I'd have to pick, think I'd keep an opaque splitter
> too. What we could do to hack around the grippy image not being shown is to use
> an image background with the grippy. What OS are you working on?
Linux, but it might be that I'm not seeing what I should be seeing because I'm using it on KDE with a theme applied to gtk apps that makes them look more like qt apps. When I have a moment I can check in Gnome. Image-wise what I'm seeing is very similar to toolkit/themes/pinstripe/global/splitter/dimple.png three times in a row. But this seems to be referenced only in pinstripe which should be Mac only? Adding it with DOM inspector doesn't work as well so it might indeed come from that gtk theme.

> We should file/find a toolkit bug to fix the splitter though.
Which part of it exactly? That it is transparent initially makes sense. That it looses visual grippy after changing -moz-appearance also makes sense. Do you mean that if grippy is added in dom, it doesn't look like one as a bug?
(Assignee)

Comment 17

7 years ago
Created attachment 477106 [details] [diff] [review]
patch to disable all shadows inside tabmail

As this will be an issue for all extensions who want to show stuff inside a tab, we might as well do it on a more global scale rather than having each and every extension turn this off.
This patch does that.
(Assignee)

Comment 18

7 years ago
only tested on Linux so far, but I'll do a quick run on Win and OS X too later today.
(Assignee)

Updated

7 years ago
Attachment #477106 - Flags: ui-review?(clarkbw)
Attachment #477106 - Flags: review?(bugzilla)
Created attachment 478527 [details] [diff] [review]
Today pane part

How about this? It makes splitter solid color on Windows and transparent on Linux (until someone fixes bug 599447). I can't check what happens on Mac so someone else should check that.

It also removes top margin from miniday so that panel title appears in the center vertically and specifies margin for event list so that space between vertical splitter and event list is equal to that between splitter and task list. Otherwise it should be the same as Screenshot - v2.
Attachment #478527 - Flags: review?(philipp)
Comment on attachment 477106 [details] [diff] [review]
patch to disable all shadows inside tabmail

seems fine to me
Attachment #477106 - Flags: ui-review?(clarkbw) → ui-review+
Agreed with Philipp to move this bug to Thunderbird component as that's where the main part of the fix is taking place.
Assignee: gasell+mozilla → nisses.mail
Component: Lightning Only → Mail Window Front End
Flags: blocking-calendar1.0+
Product: Calendar → Thunderbird
QA Contact: lightning → front-end
Whiteboard: [needed beta][no l10n impact][good first bug] → [good first bug]
Comment on attachment 477106 [details] [diff] [review]
patch to disable all shadows inside tabmail

r+a=Standard8.
Attachment #477106 - Flags: review?(bugzilla)
Attachment #477106 - Flags: review+
Attachment #477106 - Flags: approval-thunderbird3.1.5+
I've checked this into 1.9.2 to make the code freeze there as trunk is currently closed, but this is a safe-ish patch:

http://hg.mozilla.org/releases/comm-1.9.2/rev/17fbe81d6773

We'll land on trunk when it re-opens.
status-thunderbird3.1: --- → .5-fixed
Keywords: checkin-needed
OS: Linux → All
Hardware: x86 → All
Comment on attachment 478527 [details] [diff] [review]
Today pane part

Calendar part looks good. Unless Merike decides to do so beforehand, I'd appreciate if whoever checks this in could also include this patch.
Attachment #478527 - Flags: review?(philipp) → review+
(In reply to comment #22)
> Comment on attachment 477106 [details] [diff] [review]
> patch to disable all shadows inside tabmail

Checked in to trunk: http://hg.mozilla.org/comm-central/rev/23f77bea5332
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a1
Comment on attachment 478527 [details] [diff] [review]
Today pane part

Checked into trunk and 1.9.2 as requested by Philipp:

http://hg.mozilla.org/comm-central/rev/2aa4474d898d
http://hg.mozilla.org/releases/comm-1.9.2/rev/b9847d159370

Comment 27

7 years ago
Created attachment 482033 [details]
Lightning tasks

Comment 28

7 years ago
Created attachment 482034 [details]
Lightning calendar

Comment 29

7 years ago
No problem with Today Pane but still a few small problems in lightning as shown in attachment 482033 [details] and attachment 482034 [details].
(In reply to comment #29)
> No problem with Today Pane but still a few small problems in lightning as shown
> in attachment 482033 [details] and attachment 482034 [details].

Did you update Thunderbird as well? It looks like you didn't.

If your problem persists with a new version of Thunderbird please file a new bug where this can be tracked easier.

Comment 31

7 years ago
I've updated lightning to his latest nightly builds and still the same problem with task and calendar but the shadows with Today Pane have beautiful well disappeared. Would Thunderbird 3.1 be involved ?
You need to log in before you can comment on or make changes to this bug.