Open
Bug 845939
Opened 12 years ago
Updated 2 years ago
erratic behavior of checkbox in menuitem in toolbarbutton on Mac platform
Categories
(Toolkit :: Toolbars and Toolbar Customization, defect)
Tracking
()
NEW
People
(Reporter: u462496, Unassigned)
Details
Attachments
(1 file)
3.04 KB,
application/octet-stream
|
Details |
**Problem only manifests on Mac platform**
1) create toolbarbutton with menuitem type="checkbox". Do NOT initate checked state. Do NOT set closemenu attribute.
2) place toolbarbutton into the toolbar.
3) click on menuitem and observe the inability to change the appearance of the checkmark in the checkbox when toggling.
I began to uncover this bug when trying to debug the same behavior in Console2 when changing the sort order. I observed the following as well:
1) when testing the "checked" state after the item was clicked, it revealed that the "checked" state is indeed toggling, it is only that the checkmark does not appear.
2) the problem **seemed** to manifest itself most prominently if the checkbox had not been initialized with a checked state. At first appearance, it seemed that if the "checked" state was set to "true" upon initialization, the problem was not manifested. HOWEVER, continued toggling of the state will eventually cause it to stop working.
3) the problem occurred whether changing the state of the checkbox via the internal mechanism, or setting autocheck="false" and setting it programatically.
4) I could not get the problem to manifest itself if closemenu="none".
I have attached a test case.
Note that this problem is "erratic". It was very difficult to nail down a consistent manifestation of it. As I was doing version testing, I was fooled sometimes by thinking a version was not having the problem, but after opening and closing the test window, it would start to manifest. In other cases the problem was manifested right off but eventually started working after continued manipulation. I believe that the last "good" version that I have listed here does not manifest the problem. The first "bad" version is definitely bad (easier to determine something has passed the "bad" test than the "good" test.) If you are testing, please be persevering in your attempt to uncover a bad state. I thought I was going to wear my clicker out while doing version comparisons as I had to close then open the window a few times on some of them before the problem became manifest. (the more evasive ones were right near my supposed break point; don't know if that is just a coincidence or not.)
last good version: Gecko/20100204
first bad version: Gecko/20100205
Both versions were:
Mozilla/5.0
(Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.3a1pre)
Minefield/3.7a1pre
In the attached demo extension, there are four toolbarbuttons, in two groups of twos, with each toolbarbutton having a popup with two menuitems each:
In the first group all of the menuitems have the "closemenu" attribute unset, in the second group the menuitems are set with closemenu="true".
In each group, in the first button, the checked state of the menuitems in the popup are toggled internally; in the second button the states are toggled programatically.
In each popop from each button (all four buttons), the first menuitem is initialized with checked="true", the second is not initialized with a "checked" state.
(this explanation will probably be a lot clearer from examining the code :-) )
Correction: I said problem only manifests on Mac platform. More correctly it should be said that the problem does NOT manifest on Windows platform. I have not checked any other platform.
NOTE: after installing the demo extension, click on "Labodemo 3" in Tools menu to open the demo window.
A workaround that seems to work if you want the popup to close (remember, bug does not manifest with closemenu="none" on the menuitems, but then, the menu won't close either):
Put closemenu="none" on the menuitems, and put a command listener on the popup to call hidePopup().
![]() |
||
Comment 6•12 years ago
|
||
Perhaps this bug should move to Core::Widgets::Cocoa/
"Perhaps this bug should move to Core::Widgets::Cocoa/"
Is that something that I need to do?
![]() |
||
Comment 8•12 years ago
|
||
I'm going to move this bug to "Untriaged" which should attract the attention of the Firefox triagers who would then move this to a more appropriate Component.
Component: Toolbars → Untriaged
Updated•12 years ago
|
Attachment #719112 -
Attachment mime type: application/octet-stream → application/x-xpinstall
Updated•12 years ago
|
Attachment #719112 -
Attachment filename: labodemo3@labodemo.org.xpi → labodemo3@labodemoorg.xpi
Updated•12 years ago
|
Attachment #719112 -
Attachment filename: labodemo3@labodemoorg.xpi → labodemo3@labodemo.org.xpi
Attachment #719112 -
Attachment mime type: application/x-xpinstall → application/octet-stream
Comment 9•12 years ago
|
||
Seems it doesn't work for xpiinstall mimetype.
Moving to Toolbar customization.
Component: Untriaged → Toolbars and Toolbar Customization
Product: Firefox → Toolkit
Version: 4.0 Branch → 1.9.2 Branch
Reporter | ||
Comment 10•12 years ago
|
||
Been 5 months...
Anything happening?
![]() |
||
Comment 11•11 years ago
|
||
Maybe this has something to do with the behaviour Josiah experienced today. It appears that the OS X main menu toggles menuitems (type="checkbox") from checked=true to checked=false. While the appmenu and all other platforms toggle from checked=true to no checked attribute.
Allasso, can you confirm this problem still happens in current Firefox?
Flags: needinfo?(allassopraise)
Comment 12•11 years ago
|
||
I'm confirming at least for TB. I have a feeling this happens on Fx as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 13•11 years ago
|
||
Still has the same problem in FF 32.0a1 (2014-05-14). Now fails more consistently than ever.
Flags: needinfo?(allassopraise)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•