Combobox downarrow is missing, when changed from native-style to Firefox-style

NEW
Unassigned

Status

()

Core
Widget
P3
normal
10 years ago
8 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

(Depends on: 1 bug, {regression, testcase})

Trunk
regression, testcase
Points:
---
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

Created attachment 335831 [details]
reduced testcase 1

Steps to reproduce:
 1. Load URL or testcase
 2. Click the combobox (or press 'tab' to focus it)

EXPECTED BEHAVIOR:
  Combobox changes from OS-style to Firefox-Classic-Style, with a downarrow button at the far right.

ACTUAL BEHAVIOR:
  After the style-change, the downarrow button is missing.

NOTE: if you change the combobox's selected option (with arrow keys or by clicking), the downarrow button will then appear.  After it's appeared, the bug no longer reproduces, until you reload.

This appears to be cross-platform (mac + linux, at least) and it's present both in the 3.0.x branch and in the latest nightlies for trunk as well.  I've tested & seen the bug in these builds:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080820100016 Minefield/3.1a2pre
The bug doesn't reproduce in FF 2.0.0.16 (because that version doesn't use OS-style widgets).  --> regression keyword
Keywords: regression
Created attachment 335833 [details]
screenshot of bug (using reduced testcase 1 on mac)
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
Summary: Combobox downarrow is missing at first, when changed from OS-style to Firefox-style → Combobox downarrow is missing, when changed from native-style to Firefox-style
(In reply to comment #0)
> NOTE: if you change the combobox's selected option (with arrow keys or by
> clicking), the downarrow button will then appear.

Another interesting note: On Linux, at the same moment the downarrow button appears, the lower block of text jumps upwards a little bit.  I'm guessing that's because the widget changes from having the Native-style widget-height to the Firefox-style widget-height, and that triggers a reflow.  (This happens on Linux, but not on Mac -- presumably because GTK widgets are so much bigger than Firefox-style widgets, whereas mac widgets are about the same size.)

I'm not sure if this height-change is appropriate at all, but if it is, I think it should happen *when the widget-theming changes* (which would be earlier than where it's currently happening).
Hmm.  This looks similar to bug 393325, probably a duplicate, but leaving dependent for now.  The downarrow is sized to 0 by the reflow when ThemeSupportsWidget on Mac/Linux, then we remove the native styling and repaint but don't change the size of that frame.  On changing the selected option we go ahead and reflow.  That would probably account for the size thing too.
Depends on: 393325
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P3
Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
You need to log in before you can comment on or make changes to this bug.