Closed Bug 880779 Opened 11 years ago Closed 11 years ago

Entering then exiting customization on Windows leaves the 'customize-exiting' attribute on the documentElement

Categories

(Firefox :: Toolbars and Customization, defect)

All
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jaws, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P5][good first bug][mentor=jaws][lang=js])

The 'customize-exiting' attribute was added for Mac which uses a slightly different way to transition to/from customization mode. Windows doesn't use this, and it's now showing by leaving this remnant.

We should look in to building a common codepath and not leaving these types of attributes behind.
P5 unless there's some actual user-impact.
Whiteboard: [Australis:P5]
To fix this bug, you'll need to clone the repository at https://hg.mozilla.org/projects/ux/. The changes will need to be made in /browser/components/customizableui/CustomizeMode.jsm.
Whiteboard: [Australis:P5] → [Australis:P5][good-first-bug][mentor=jaws][lang=js]
Assignee: nobody → allamsetty.anup
Status: NEW → ASSIGNED
Whiteboard: [Australis:P5][good-first-bug][mentor=jaws][lang=js] → [Australis:P5][good first bug][mentor=jaws][lang=js]
Some more context, when exiting customization mode we always place the 'customize-exiting' attribute on the documentElement.

However, based on how we handle our CSS transition to exit customization mode, we end up having two paths that the code can take (one for Windows+Linux, and one for Mac).

The code path for Mac removes the customize-exiting attribute, but the one for Windows doesn't. This is what we'll need to fix.
Assignee: allamsetty.anup → nobody
Status: ASSIGNED → NEW
I can't reproduce the original issue on Windows, and neither can mconley. Marking WFM.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.