1213152 - Disable GTK3 in comm-release for SeaMonkey

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Edmund Wong (:ewong)]

Due to issues pertaining to the enabling of GTK3 (and also the fact
that both Firefox and TB have removed the GTK3 package from the
releng.manifest), we'll need to do that as well.

Comment 1

[Edmund Wong (:ewong)]

Attachment: [tooltool] proposed patch(v1) [2.39 beta] [checked-in]

Comment 2

[Philip Chee]

Comment on attachment 8671719 [details] [diff] [review]
[tooltool] proposed patch(v1) [2.39 beta] [checked-in]

Looks reasonable

r=me a=comm-beta

Comment 3

[Edmund Wong (:ewong)]

Comment on attachment 8671719 [details] [diff] [review]
[tooltool] proposed patch(v1) [2.39 beta] [checked-in]

Pushed to comm-beta:
https://hg.mozilla.org/releases/comm-beta/rev/cc17ff4c7679

Comment 4

[Edmund Wong (:ewong)]

Attachment: [tooltool] fix to replace the setup.sh.

Pushing for post-land-review

Comment 5

[Edmund Wong (:ewong)]

Comment on attachment 8674124 [details] [diff] [review]
[tooltool] fix to replace the setup.sh.

Pushed to comm-beta:
https://hg.mozilla.org/releases/comm-beta/rev/8e5e4348ad9e

Comment 6

[Edmund Wong (:ewong)]

Attachment: [tooltool] fix to replace setup.sh (v2) [checked-in]

[Triage Comment]
Backed out http://hg.mozilla.org/releases/comm-beta/rev/8e5e4348ad9e

This patch will be for post-land-review.

Comment 7

[Edmund Wong (:ewong)]

Comment on attachment 8674634 [details] [diff] [review]
[tooltool] fix to replace setup.sh (v2) [checked-in]

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: None for users; but automation fails to build.
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):
String changes made by this patch: None

Comment 8

[Edmund Wong (:ewong)]

Comment on attachment 8674634 [details] [diff] [review]
[tooltool] fix to replace setup.sh (v2) [checked-in]

Pushed to comm-beta:
http://hg.mozilla.org/releases/comm-beta/rev/8460ab5e4d5c

Comment 9

[Edmund Wong (:ewong)]

Apparently m-b has switched to gtk2. (bug 1227024)

Comment 10

[Edmund Wong (:ewong)]

Attachment: [tooltool] proposed patch for 2.40 (c-r) (v1) [checked-in]

Comment 11

[Edmund Wong (:ewong)]

Comment on attachment 8691236 [details] [diff] [review]
[tooltool] proposed patch for 2.40 (c-r) (v1) [checked-in]

This was never pushed to comm-beta and now that c-r is 2.40,
this could just as well be causing the Linux* bustages.

Comment 12

[Edmund Wong (:ewong)]

Comment on attachment 8691236 [details] [diff] [review]
[tooltool] proposed patch for 2.40 (c-r) (v1) [checked-in]

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined:  cannot build in a Linux platform
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):
String changes made by this patch:

Comment 13

[Edmund Wong (:ewong)]

Comment on attachment 8691236 [details] [diff] [review]
[tooltool] proposed patch for 2.40 (c-r) (v1) [checked-in]

Pushed to comm-release:
https://hg.mozilla.org/releases/comm-release/rev/860e55fe632e

Comment 14

[Edmund Wong (:ewong)]

Attachment: [tooltool] setup.sh fix for bustage. [checked-in]

[Approval Request Comment]
Regression caused by (bug #): 1213152's c-r patch
User impact if declined: cannot bbuild Linux* w/ tooltool
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):
String changes made by this patch:

Comment 15

[Edmund Wong (:ewong)]

Comment on attachment 8707773 [details] [diff] [review]
[tooltool] setup.sh fix for bustage. [checked-in]

https://hg.mozilla.org/releases/comm-release/rev/d78e9b3b660a

Comment 16

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] remove no_tooltool=1 from mozconfigs.

Comment 18

[rsx11m]

Needs to be disabled again for the upcoming <s>2.44</s>2.45 release.

Comment 19

[Adrian Kalla [:adriank]]

(In reply to rsx11m from comment #18)
> Needs to be disabled again for the upcoming <s>2.44</s>2.45 release.

Short question: why? (afaik Fx from m-r already uses GTK3)

Comment 20

[rsx11m]

Because it seems to be incomplete for the SM default theme, which apparently relies heavily on the desktop theme providing styles for elements, which however many desktop themes don't style.

See Frank's posts in http://forums.mozillazine.org/viewtopic.php?f=3&t=2973875&start=180

It works for Firefox because apparently they've taken better care of such dependencies.

Comment 21

[rsx11m]

FWIW, OpenSUSE 13.2 provides Firefox 47.0 builds with GTK2 only as well in their repositories.

Comment 22

[Adrian Kalla [:adriank]]

(In reply to rsx11m from comment #20)
> Because it seems to be incomplete for the SM default theme, which apparently
> relies heavily on the desktop theme providing styles for elements, which
> however many desktop themes don't style.
> 
> See Frank's posts in
> http://forums.mozillazine.org/viewtopic.php?f=3&t=2973875&start=180

Ok - I didn't notice any of these problems apparently because my desktop theme takes care of everything.

Comment 23

[Frank Lion]

Just to, hopefully, clarify a couple of things. The non-appearance of scrollbar arrows is not a GTK3 bug, but the omission of just 2 lines of code in gtk.css by many Linux OS theme writers, especially Mint. It shows far more in browsers, but this omission is evident in other programs that have scrollbars and use GTK3, such as Nemo, a main file manager. As so many Linux theme writers have mucked this up (a 100% working default theme template would have helped) it is assumed by users to be a GTK3/OS or browser bug. It 'may' be possible to add the required 2 lines in SeaMonkey's chrome://global/content/bindings/scrollbar.xml#scrollbar.

The other glitch that has recently been pointed out to me, is menus without borders that blend into the background. That is not GTK3 one, where menu borders are pretty easy to code, but an old GTK2 one, where they are pretty difficult to code right. 

To fix that one, I suggest something like this - arrowscrollbox:not(.tabbrowser-arrowscrollbox) {
 border: 1px solid grey !important;} (that is a userChrome.css fix, so !important not required usually)  - doesn't interfere with or override native -moz-appearance menu OS coding, works with both light and dark native themes and doesn't mess up 3rd party SM themes. A manifest flag could be used to make it Linux OS specific, if required.  

My own suggestion on this bug is that we implement the above menu border fix and drop GTK3, until such a time that the Linux community has learned how to use it properly. GTK3 is actually a FAR better UI theming system than GTK2, but only if used correctly. In fairness, none of that Linux stuff is exactly easy to theme.

Comment 24

[rsx11m]

Thanks Frank, I've added the information of your first paragraph to the scroll-bar bug 1269145.

Comment 25

[Frank Lion]

(In reply to rsx11m from comment #24)
> Thanks Frank, I've added the information of your first paragraph to the
> scroll-bar bug 1269145.

No problem. all that I wrote there is correct, but we can fix this! Add the following to SM's default scrollbars.css - 

scrollbarbutton[sbattr="scrollbar-up-bottom"],
scrollbarbutton[sbattr="scrollbar-down-top"] {
  display: none;
}
scrollbarbutton[sbattr="scrollbar-up-top"],
scrollbarbutton[sbattr="scrollbar-down-bottom"] {
  display: -moz-box !important;
}

Quick Reproduce: Put this theme on - https://addons.mozilla.org/en-us/seamonkey/addon/metal-lion-sea-monkey/?src=cb-dl-updated and any Linux OS theme that is known to vanish the scrollbar arrows. As expected, upon SM restart, arrows are gone and same with default, etc.

Now take the scrollbar.xpi that comes with that theme, which uses 'override' to, er, override the default scrollbar.css. Edit the scrollbars.css of the .xpi and add the above code around line 124. Save, restart, etc. the arrows are back and you're done. Putting a 'good' Linux theme on later has no adverse effect. 

Obviously, the code is added to default's scrollbar.css as a proper fix, but I'm spelling out the above method, so that other people can test this out for themselves. But, I've tested and can't break it. 

Lucky you linked to that scrollbar bug, I read the comments and picked up the fact that Early Bird was not getting whacked by this and that is where this fix comes from. :)

Comment 26

[Edmund Wong (:ewong)]

(In reply to rsx11m from comment #18)
> Needs to be disabled again for the upcoming <s>2.44</s>2.45 release.

Given Frank's response in comment #25, I'm guessing we don't need to
repeat that disable gtk3.

Comment 27

[rsx11m]

I disagree with that conclusion; the scrollbar is one thing (and handled in a different bug which yet has to be solved), there are other issues with GTK3 which we should address in the default theme first before making GTK3 the standard.

Also, switching to GTK3 marks end of the line for those builds with older distros which don't support GTK3 (including still active long term support distros, which may or may not have their own builds).

Comment 28

[Edmund Wong (:ewong)]

(In reply to rsx11m from comment #27)
> I disagree with that conclusion; the scrollbar is one thing (and handled in
> a different bug which yet has to be solved), there are other issues with
> GTK3 which we should address in the default theme first before making GTK3
> the standard.
> 
> Also, switching to GTK3 marks end of the line for those builds with older
> distros which don't support GTK3 (including still active long term support
> distros, which may or may not have their own builds).

Fair enough. 

So to clarify...  disable GTK3 in 2.45, right?  2.44 is pretty much a moot
point now.

Comment 29

[rsx11m]

(In reply to Edmund Wong (:ewong) from comment #28)
> So to clarify...  disable GTK3 in 2.45, right?

Yes, please - assuming that 2.44 is skipped and thus can be won't-fixed.

Comment 30

[Ian Neal]

Agreed

Comment 31

[Edmund Wong (:ewong)]

Comment on attachment 8709230 [details] [diff] [review]
[mozconfigs] remove no_tooltool=1 from mozconfigs.

This patch is no longer applicable as it was fixed in a 2.46 based
patch.

Comment 32

[Frank-Rainer Grahl (:frg)]

gtk3 is now the default with 2.49.1. Can we close this one?

Comment 33

[rsx11m]

(In reply to Frank-Rainer Grahl (:frg) from comment #32)
> Can we close this one?

I'd think so, unless we run into any (very late) roadblocks for switching to GTK3.
There is still meta bug 1367257 to keep track of pending issues yet to be solved.

What's with the review/approval requests for attachment 8707773 [details] [diff] [review]?

Comment 34

[Edmund Wong (:ewong)]

sure.. closing.