erratic behavior of checkbox in menuitem in toolbarbutton on Mac platform




6 years ago
11 months ago


(Reporter: u462496, Unassigned)


1.9.2 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
Created attachment 719112 [details]
test case (.xpi) demonstrating the behaviour encountered

**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:

(Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.3a1pre)

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 :-) )

Comment 1

6 years ago
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.

Comment 2

6 years ago
This problem is still present as of the latest Nightly.

Comment 3

6 years ago
22.0a1 (2013-02-27)

Comment 4

6 years ago
NOTE: after installing the demo extension, click on "Labodemo 3" in Tools menu to open the demo window.

Comment 5

6 years ago
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

6 years ago
Perhaps this bug should move to Core::Widgets::Cocoa/

Comment 7

6 years ago
"Perhaps this bug should move to Core::Widgets::Cocoa/"

Is that something that I need to do?

Comment 8

6 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
Attachment #719112 - Attachment mime type: application/octet-stream → application/x-xpinstall
Attachment #719112 - Attachment filename: → labodemo3@labodemoorg.xpi
Attachment #719112 - Attachment filename: labodemo3@labodemoorg.xpi →
Attachment #719112 - Attachment mime type: application/x-xpinstall → application/octet-stream
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

Comment 10

5 years ago
Been 5 months...

Anything happening?

Comment 11

5 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)
I'm confirming at least for TB. I have a feeling this happens on Fx as well.
Ever confirmed: true

Comment 13

5 years ago
Still has the same problem in FF 32.0a1 (2014-05-14).  Now fails more consistently than ever.
Flags: needinfo?(allassopraise)
You need to log in before you can comment on or make changes to this bug.