Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
- Content embedded by SubDialog can define its own focus handler which will be called on SubDialog#focus
- Updated CommonDialog to register custom focus handler
- Moved focus calls from SubDialog to SubDialogManager
- Return early after tab dialog focus on tab switch
Differential Revision: https://phabricator.services.mozilla.com/D102298
- Content embedded by SubDialog can define its own focus handler which will be called on SubDialog#focus
- Updated CommonDialog to register custom focus handler
- Moved focus calls from SubDialog to SubDialogManager
- Return early after tab dialog focus on tab switch
Differential Revision: https://phabricator.services.mozilla.com/D102298
- Content embedded by SubDialog can define its own focus handler which will be called on SubDialog#focus
- Updated CommonDialog to register custom focus handler
- Moved focus calls from SubDialog to SubDialogManager
- Return early after tab dialog focus on tab switch
Differential Revision: https://phabricator.services.mozilla.com/D102298
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
The TabDialogBox will manage two separate SubDialog managers at the tab and content level. Dialogs managed at the tab level will always be on top of content ones and should always receive focus first when tab switching or refocusing the window.
Differential Revision: https://phabricator.services.mozilla.com/D100066
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
The TabDialogBox will manage two separate SubDialog managers at the tab and content level. Dialogs managed at the tab level will always be on top of content ones and should always receive focus first when tab switching or refocusing the window.
Differential Revision: https://phabricator.services.mozilla.com/D100066
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
The TabDialogBox will manage two separate SubDialog managers at the tab and content level. Dialogs managed at the tab level will always be on top of content ones and should always receive focus first when tab switching or refocusing the window.
Differential Revision: https://phabricator.services.mozilla.com/D100066
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
When the user chooses to print using the system dialog, we should hide the print
UI. We are choosing to hide the dialog stack instead of closing the dialog because
the print preview browser still needs to be available if the user tries to print.
We close the window if the user cancels the system dialog or once we receive the
promise from PrintUtils.printWindow.
Differential Revision: https://phabricator.services.mozilla.com/D88096
