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)

1.9.2 Branch
x86
macOS
defect

Tracking

()

People

(Reporter: u462496, Unassigned)

Details

Attachments

(1 file)

**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.
This problem is still present as of the latest Nightly.
22.0a1 (2013-02-27)
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().
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?
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@labodemo.org.xpi → labodemo3@labodemoorg.xpi
Attachment #719112 - Attachment filename: labodemo3@labodemoorg.xpi → labodemo3@labodemo.org.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
Been 5 months... Anything happening?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Still has the same problem in FF 32.0a1 (2014-05-14). Now fails more consistently than ever.
Flags: needinfo?(allassopraise)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: