Closed Bug 309315 Opened 19 years ago Closed 17 years ago

Toolbarbutton type="checkbox" XUL element doesn't check on Linux

Categories

(Firefox :: Toolbars and Customization, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 334596

People

(Reporter: leonardomateo, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

The <toobarbutton type="checkbox"> and/or type="radio" XUL element doesn't act
as a toggle button (doesn't keep checked), instead it behaves as a normal
button. It only happens on Linux platform but not in Windows, in Windows it acts
as it should. Both, Linux and Windows, Firefox versions are 1.0.6
I've tried with Firefox 1.5 Beta 1 on Linux and still not working.

Reproducible: Always

Steps to Reproduce:
1.Create a simple XUL page with a toolbar and a toolbarbutton on it.
2.Browse this page.
3.Here comes some example code.
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

<window id="main-window" title="Window Title" orient="horizontal"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<toolbar orient="vertical">
 <toolbarbutton type="radio" checked="true" label="Button 1"/>
 <toolbarbutton type="radio" label="Button 2"/>
</toolbar>
</window>
Actual Results:  
The page is shown (almost) as expected but not behaves as espected. The buttons
on the toolbar acts as normal buttons (on click, get pressed and then unpressed
on mouseup) but not as toggle buttons as espected (on click, get pressed until
the next click) on Linux platform, but it does on Windows.

Expected Results:  
Make the button act as a toggle button, just the same way it does on Windows.
Confirmed with Firefox 2.0.0.4 on Linux/Windows.

Here's my test case: http://tlau.org/test.xul

On Linux, the button does act like a toggle button, but the button appearance does not change to the depressed state when it has been pushed.  The value of the "checked" attribute does behave as normal, it's just the appearance that doesn't match.

On Windows, when the button is checked, the image appears depressed (lighter gray background, sunken border) and when the button is unchecked, the image is not rendered as depressed.
I noticed that you cannot set background-image nor background-color css styles on toolbarbuttons. That's the reason why rules set for toolbarbutton[checked="true"] (in toolbarbutton.css) are not applied.

But if you remove  "-moz-appearance: toolbarbutton;" occurences in toolbarbutton.css, you will then notice a visual difference between checked and unchecked state.

So it looks like native gtk appearance prevents to set some css properties on toolbarbuttons.

I tried differents gtk2 themes, and problem was there with every theme, so it does not seem related to a specific gtk theme.

Also, could that bug be related to (or be a dupe of) bug 254002 ?
It's definitely related to bug 254002 but I can't view the test cases there (error 403 forbidden on the server) so I can't verify that it's exactly the same bug.
Hi I posted something related to that bug in mozilla forums http://forums.mozillazine.org/viewtopic.php?p=3035527#3035527

Someone using a prerelease of firefox 3.0 told he did not have the problem. I tested with a nightly and bug seems to be fixed. Is problem fixed for you also with a nightly build or a prerelease ?
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.