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

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Jonathan Protzenko [:protz]]

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.

Comment 1

[Jonathan Protzenko [:protz]]

Attachment: Screenshot of the issue.

Comment 2

[Stefan Sitter [:ssitter]]

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? ...

Comment 3

[Jonathan Protzenko [:protz]]

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".

Comment 5

[Mark Banner (:standard8)]

It is even worse with some other personas, e.g. IceAge. Personas is probably going to become more prominent in TB 3.2...

Comment 6

[Nicolas LECORNU]

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.

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

We should try to fix this for the next beta, this is probably low hanging fruit.

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: 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+

Comment 9

[Andreas Nilsson (:andreasn)]

"Stealing" this UI review from Bryan

Comment 10

[Andreas Nilsson (:andreasn)]

Comment on attachment 467733 [details]
Screenshot - v2

Looks great. Lets do that!

Comment 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Merike, since you already have some code, do you want to create a patch for this?

Comment 12

[Merike Sell (:merike)]

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..

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 14

[Merike Sell (:merike)]

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.

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 16

[Merike Sell (:merike)]

(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?

Comment 17

[Andreas Nilsson (:andreasn)]

Attachment: 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.

Comment 18

[Andreas Nilsson (:andreasn)]

only tested on Linux so far, but I'll do a quick run on Win and OS X too later today.

Comment 19

[Merike Sell (:merike)]

Attachment: 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.

Comment 20

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 477106 [details] [diff] [review]
patch to disable all shadows inside tabmail

seems fine to me

Comment 21

[Mark Banner (:standard8)]

Agreed with Philipp to move this bug to Thunderbird component as that's where the main part of the fix is taking place.

Comment 22

[Mark Banner (:standard8)]

Comment on attachment 477106 [details] [diff] [review]
patch to disable all shadows inside tabmail

r+a=Standard8.

Comment 23

[Mark Banner (:standard8)]

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.

Comment 24

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 25

[Mark Banner (:standard8)]

(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

Comment 26

[Mark Banner (:standard8)]

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

[Nicolas LECORNU]

Attachment: Lightning tasks

Comment 28

[Nicolas LECORNU]

Attachment: Lightning calendar

Comment 29

[Nicolas LECORNU]

No problem with Today Pane but still a few small problems in lightning as shown in attachment 482033 [details] and attachment 482034 [details].

Comment 30

[Mark Banner (:standard8)]

(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

[Nicolas LECORNU]

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 ?