563886 - Firefox broken with mozilla.widget.disable-native-theme=true

Status: NEW

(Firefox :: Theme, defect)

Description

[Clemens Eisserer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

Because of performance-problems when using the native theme (e.g. gmail's inbox-page painting takes 2.5x as long as without native theming) I disabled the use of gtk for firefox' widgets using:

mozilla.widget.disable-native-theme;true

Everything seems to work quite fine and performance is great, however firefox' main window itself seems to struggle a bit:

- The URL entry box doesn't have any background nore border
- Menus as well as tooltips don't have a background color, and therefor look transparent (and are horrible slow)

It would be great if that could be fixed.

Reproducible: Always

Steps to Reproduce:
1. set mozilla.widget.disable-native-theme;true
2. restart firefox
3. menus are now transparent, url entry bar has no border/background

Comment 1

[Clemens Eisserer]

Attachment: screenshot of firefox' main window with native theme disabled

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I wonder if we shouldn't have a pref that just disables it for content, since that's where you see OMGTONS of form elements and such.  Copying some Linux types.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, that would be relatively straightforward.  To add a second pref, we could:

Add a second pref whose value is loaded like the existing one:
http://mxr.mozilla.org/mozilla-central/search?string=gDisableNativeTheme
but instead of checking it in the factory methods like the current one is, check it at the start of each platform's implementation of nsITheme::IsWidgetStyled, with a check like:

  if (gDisableNativeThemeInContent && !aPresContext->IsChrome())
    return PR_FALSE;

We'd also need to tweak nsPresContext::IsChromeSlow to be callable from outside the layout library; this could be done just like nsPresCnotext::GetContainer or nsPresContext::SetImageAnimationMode.

Comment 4

[Karl Tomlinson (:karlt)]

(In reply to comment #0)
> Because of performance-problems when using the native theme (e.g. gmail's
> inbox-page painting takes 2.5x as long as without native theming)

Dragging another window across the checkboxes in Gmail (without a compositing window manager) makes it clear that they are causing a performance problem.  This suggests that our slow path is being used here, but that is likely unnecessary.  We could probably speed that up considerably.

Comment 5

[Karl Tomlinson (:karlt)]

Bug 537860 comment 11 suggests that changes in bug 402940 might have triggered something.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I also wonder whether we should cache (for, say, 10-60 seconds) recently-used native theme images.

Comment 7

[Clemens Eisserer]

I see the same on another system (radeon mobility m9).

When dragging a window over the gmail-inbox repaint is almost instant if I don't move it over the checkboxes. As soon as form-elements have to be repainted, the whole painting process is slowed down a lot.

1.) Yeah, whats up with caching?
2.) GTK-3 hopefully will provide xml based themeing with an external theming-library. So hopefully the whole roundtrip-theming will come to an end sooner or later.

Comment 8

[Karl Tomlinson (:karlt)]

(In reply to comment #7)
> When dragging a window over the gmail-inbox repaint is almost instant if I
> don't move it over the checkboxes. As soon as form-elements have to be
> repainted, the whole painting process is slowed down a lot.

Bug 444870 will address that.

(In reply to comment #6)
> I also wonder whether we should cache (for, say, 10-60 seconds) recently-used
> native theme images.

The problem with caching atm is that we'd have to cache a copy with alpha values but that (currently) requires the slow path.

Some native themes are starting to support RGBA visuals
https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/491521/comments/73
but it sounds like it is probably actually drawing something different when using those visuals, so I'm not sure whether that's what we want or not.

Retained layers will do some caching for us.

Comment 9

[:aceman]

I think retained layers have already been included. Was anything improved with the caching?

Anyway, I can confirm that the menu and location bar problem is still the same on FF4b7pre. It seems the transparency part was moved to bug 564110.

Comment 10

[Clemens Eisserer]

still broken in Firefox-13, page rendering still seems to take a huge boost by disabling native theming.

Comment 11

[Clemens Eisserer]

still broken with nightly 58a1