719050 - Lightning aero #button-delete style makes the SeaMonkey Mail delete button image disappear.

Status: RESOLVED FIXED

(Calendar :: Lightning: SeaMonkey Integration, defect)

Comment 1

[Philip Chee]

Attachment: Patch v1.0 Make style rule more specific.

Simple one line fix:

> -#button-delete {
> +#button-delete.cal-event-toolbarbutton {

Comment 2

[Richard Marti (:Paenglab)]

Comment on attachment 589516 [details] [diff] [review]
Patch v1.0 Make style rule more specific.

I checked it only under TB and it looks as without this patch (I haven't expected a change ;)). I suppose you have checked it under SM.

So ui-r+

Comment 3

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

Comment on attachment 589516 [details] [diff] [review]
Patch v1.0 Make style rule more specific.

Are there more buttons that could have this problem? Maybe we could fix them all at once.

Comment 4

[Philip Chee]

> I checked it only under TB and it looks as without this patch (I haven't
> expected a change ;)). I suppose you have checked it under SM.

This patch works in SM of course. The reason the unpatched CSS doesn't affect
Thunderbird's #button-delete is that TB applies the list-style-image to the
two sub buttons, while SeaMonkey applies the image to the enclosing toolbaritem.

> Are there more buttons that could have this problem? Maybe we could fix them
> all at once.

I only did a quick check and the only other styles that lack sufficient
specificity are:

#button-save {
  -moz-image-region: rect(0 108px 18px 90px) !important;
}

#button-attendees {
  -moz-image-region: rect(0 36px 18px 18px) !important;
}

#button-privacy {
  -moz-image-region: rect(0 90px 18px 72px) !important;
}

#button-url {
  -moz-image-region: rect(0 72px 18px 54px) !important;
}

Fortunately these IDs don't exist in the SeaMonkey messenger.xul. I didn't
check Thunderbird.

Comment 5

[Stefan Sitter [:ssitter]]

From a quick look the rules all belong only to calendar-event-dialog.xul. 
I think there is no need to apply them to the whole SeaMonkey/Thunderbird window at all.

Comment 6

[Richard Marti (:Paenglab)]

(In reply to Philip Chee from comment #4)
> I only did a quick check and the only other styles that lack sufficient
> specificity are:
> 
> #button-save {
> ...
> #button-attendees {
> ...
> #button-privacy {
> ...
> #button-url {
> ...

This are all IDs and normally unique so they are strong enough defined.

Only #button-delete and #button-print aren't unique (TB and I think SM are also using this IDs) and this makes this problems. I think I'll file a new bug to change this IDs in Lightning.

Comment 7

[Philip Chee]

(In reply to Stefan Sitter from comment #5)
> From a quick look the rules all belong only to calendar-event-dialog.xul. 
> I think there is no need to apply them to the whole SeaMonkey/Thunderbird
> window at all.

calendar/base/jar.mn has these:

% style chrome://calendar/content/calendar-event-dialog.xul chrome://calendar-windows/skin/calendar.css os=WINNT osversion>=6
% style chrome://calendar/content/calendar-occurrence-prompt.xul chrome://calendar-windows/skin/calendar.css os=WINNT osversion>=6
% skin calendar-windows classic/1.0 chrome/calendar/skin/calendar/win-classic/ os=WINNT osversion<6
% skin calendar-windows classic/1.0 chrome/calendar/skin/calendar/win-aero/ os=WINNT osversion>=6

Excuse me for saying this but trying to unwind your Byzantine jar.mn's made me go cross-eyed.

Comment 8

[Philip Chee]

Comment on attachment 589516 [details] [diff] [review]
Patch v1.0 Make style rule more specific.

Pushed to comm-central
http://hg.mozilla.org/comm-central/rev/17750def9679

[Approval Request Comment]
Regression caused by some patch or other.
User impact if declined: Makes SeaMonkey Mail Delete button image disappear.
Risk to taking this patch (and alternatives if risky): No known risk on Thunderbird or Lightning or Sunbird.

Comment 9

[Alex Keybl [:akeybl]]

Comment on attachment 589516 [details] [diff] [review]
Patch v1.0 Make style rule more specific.

I believe only changes from m-c use the Firefox approval process - please email me if that doesn't end up being the case.

Comment 10

[Philip Chee]

> I believe only changes from m-c use the Firefox approval process - please email me if
> that doesn't end up being the case.
Dunno. These are the flags that the Lighting drivers set up so presumably they use them?

Comment 11

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

Comment on attachment 589516 [details] [diff] [review]
Patch v1.0 Make style rule more specific.

Product Calendar is taking care of the approval flags on its own, as it was decided that more flags are not wanted. I've recently seen approval-comm-* flags, so we might switch to them.

As Calendar owner I approve these for beta and aurora. Please push the beta patch asap, as I'd like to create a new beta build soon.

Comment 12

[Philip Chee]

Pushed:
http://hg.mozilla.org/releases/comm-aurora/rev/e745a2e5db84
http://hg.mozilla.org/releases/comm-beta/rev/deacf4a46895

Was some bit rot on comm-beta since the file name changed from comm-beta to comm-aurora but otherwise the patch is identical.

Comment 13

[Martin Schröder [:mschroeder]]

This fix has been pushed to comm-beta. Setting the target milestone to 1.2!