Embarrassingly, I forgot I added this in bug 1388990 when we had similar issues
with the back/forward buttons. It's a more straightforward solution for this
problem.
Differential Revision: https://phabricator.services.mozilla.com/D94751
This is using collapsed as a carryover from XBL days, where setting the element to hidden would destroy bindings.
But it's causing a side effect of shrinking the browser element to 0x0 which causes the content to resize, leading to
some flickering and poor performance when switching back to content from a Customize Mode tab.
By setting hidden we instead are just toggling the display property.
Differential Revision: https://phabricator.services.mozilla.com/D94057
When we move items in customize mode, we unwrap them, then move them, then wrap
them again. The unwrapping sets the `command` attribute back on the button, and
that also sets the `disabled` attribute on the button. The wrapping removes the
`command` attribute but leaves the `disabled` attribute.
When the `disabled` attribute is removed from the command, this does not
propagate to the button because the command attribute has not been put back.
To fix this, the patch avoids adding and immediately removing the command
attribute when moving items while in customize mode.
Differential Revision: https://phabricator.services.mozilla.com/D93338
Before this patch, we change aDraggedItemId somewhat late in the _applyDrop method -
significantly, we do this after the aTargetNode == areaCustomizationTarget check. So
we end up bailing out before adjusting aDraggedItemId, and we add the specific dummy
item from the palette into the toolbar, rather than adding a new spring to the
toolbar, and leaving the existing palette item alone.
Simply moving this adjustment to aDraggedItemId earlier into the method is sufficient
to fix the issue at hand.
Differential Revision: https://phabricator.services.mozilla.com/D62948
All usage of `synthesizeDragStart()` is, starting drag, cancel `dragstart`,
and finally compares `dataTransfer` items and given expected data. So,
we can make the users use `synthesizePlainDragAndDrop()` instead. It's
better API because it computes position of mouse operations at runtime and
checks whether the drag start was succeeded with optional logging feature
(i.e., it's easier to debug of intermittent failures).
This patch creates `synthesizePlainDragAndCancel()` for convenience. It
handles `dragstart` instead of the callers.
Differential Revision: https://phabricator.services.mozilla.com/D58214
This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.
Differential Revision: https://phabricator.services.mozilla.com/D35085
This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.
Differential Revision: https://phabricator.services.mozilla.com/D35085
This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.
Differential Revision: https://phabricator.services.mozilla.com/D35085
This isn't necessary, since it has only 2 static children (the selected tab's content
and the customizable UI), and their visibility is toggled in a single place. We already
toggle .hidden for both - there's no need for a separate deck.
Differential Revision: https://phabricator.services.mozilla.com/D34792
These are generally:
- Code comments to browser.xhtml
- Testcases, assertions that were mostly using browser.xul as a generic chrome URL
- References to the browser.xul path in tree
Differential Revision: https://phabricator.services.mozilla.com/D33208
