There was only a min-height: 0 missing. I also cleaned-up a bit because
flex: 1 is the same as flex: 1 1 auto, and flex attribute (which only
sets -moz-box-flex) is not doing anything because it was inside flex
layout (so legacy properties aren't looked at).
Differential Revision: https://phabricator.services.mozilla.com/D160094
Incorporates the "Places Database Statistics" table from `chrome://browser/content/places/interactionsViewer.html` into the `about:support` page, under the existing "Places Database" table. The table is hidden by default, and it can be toggled on/off using a button. Table contents will always be part of the "Copy text to clipboard" export, regardless of visibility.
Try Job: https://treeherder.mozilla.org/jobs?revision=923a9df8c477f6e2b1f0a2fee3b0291ddbdd32e3&repo=try
Initial state:
{F4177493}
After clicking "Show Statistics":
{F4177495}
Text export:
{F4177496}
Differential Revision: https://phabricator.services.mozilla.com/D158200
This was used to prevent reflows due to popuppositioned events during
view transitions.
The previous patch should've prevented the popuppositioned events to
begin with, plus we no longer use arrows that need positioning etc,
which means we shouldn't be triggering the reflows anyways.
Since this is the only consumer of autoPosition = true/false, we can
remove the code supporting it. It's a bit bogus as per the commit
message of the previous patch and, while fixable, it doesn't seem worth
fixing if we can just get rid of it.
Depends on D159936
Differential Revision: https://phabricator.services.mozilla.com/D159937
getOuterScreenRect doesn't flush layout, so not flushing here should be
fine.
We only care about the CSS width / height, not about the screen
positioning, so this is more accurate.
The flickering in comment 8 (the hover effect in the "restore previous
session" button) happens because the following set of events:
* We try to lock the size of the panel.
* The size returned by getOuterScreenRect() is fractionally different
to the actual size.
* We get to [1], realize we've changed size (even though fractionally),
set the origin at 0, 0, and then call SetPopupPosition to fix that
up.
* But we've disabled autopositioning[1], so the layout position of the
panel remains at 0, 0.
This prevents the flickering by using the actual layout size
(getBoundsWithoutFlushing / getBoundingClientRect) rather than the
potentially-rounded getOuterScreenRect, to prevent the resize.
We could fix autoPosition = false, but I don't think it's needed
anymore, so I'm going to try removing it instead. However this change
should still avoid work, so seems worth landing regardless.
[1]: https://searchfox.org/mozilla-central/rev/c5c002f81f08a73e04868e0c2bf0eb113f200b03/layout/xul/nsMenuPopupFrame.cpp#621-626
[2]: https://searchfox.org/mozilla-central/rev/c5c002f81f08a73e04868e0c2bf0eb113f200b03/browser/components/customizableui/PanelMultiView.jsm#668
Depends on D159935
Differential Revision: https://phabricator.services.mozilla.com/D159936
While these work now because I haven't ported popups to modern flexbox,
let's remove usage of these attributes so I don't have to later. This
doesn't change behavior.
Depends on D159934
Differential Revision: https://phabricator.services.mozilla.com/D159935
This reverts the fix to bug 1731373 and instead makes Firefox Suggest wait for
TelemetryEnvironment to finish initializing before it starts to update its
preferences. That's what I should have done in the first place, no need for an
observer notification or for TelemetryEnvironment to have to know any details
about Suggest prefs.
This fixes the bug (bug 1796202) and should also avoid the problem for any other
Suggest prefs we add to TelemetryEnvironment in the future.
Differential Revision: https://phabricator.services.mozilla.com/D159820
By using delegatesanchor="true", we delegate the anchor node to the
first in-flow box (that is the icon), simplifying a lot of the
hard-coded margins in the CSS.
Do that, plus make menupopup[type="arrow"] work consistently, to
simplify the styling of the bookmarks popup a bit.
Differential Revision: https://phabricator.services.mozilla.com/D158569
This fixes the edit bookmarks dialog by properly allowing stuff to wrap once
the dialog width has been fixed.
Let's try to do this and opt-out any specific pages that may hit issues,
rather than opting-in one by one, now that's early in the cycle?
Differential Revision: https://phabricator.services.mozilla.com/D159690
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
I opted to add a pref and effectively disable things by default rather than
just removing everything, because it seems likely we'll want to re-introduce
this in some form at some point soon, plus this is a much smaller change to
uplift and keeps the test coverage for now, too.
Differential Revision: https://phabricator.services.mozilla.com/D159707
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
This fixes the edit bookmarks dialog by properly allowing stuff to wrap once
the dialog width has been fixed.
Let's try to do this and opt-out any specific pages that may hit issues,
rather than opting-in one by one, now that's early in the cycle?
Differential Revision: https://phabricator.services.mozilla.com/D159690
The sitePermissions code is reused, and all dialogs work OK except the autoplay one.
This is because the autoplay code adds extra content not present in the other
dialogs, and localizes it.
The SubDialog code relies on determining the size of the dialog once the
mozSubDialogReady promise resolves, which it does before fluent puts in l10n data
for the content that was just added. This patch fixes that.
It also, as a driveby, correctly pauses and resumes observing l10n attributes
in the doc when making modifications, to avoid fluent doing a second pass for
the same content.
Differential Revision: https://phabricator.services.mozilla.com/D159543
It seems that at build time, we already make decisions about what migrators we register
with XPCOM in browser/components/migration/components.conf. This doesn't, however, give
us the ability to turn off a migrator that happens to be misbehaving, nor make it easy
for us to do development of a new migrator without exposing it to the migration dialog
(without doing binary recompiles).
This adds another layer to the enable-ment of our migrators so that they must both
be registered AND enabled in order to appear in the import dialog.
Differential Revision: https://phabricator.services.mozilla.com/D159544
On Wayland drop target position can be a negative value. Drop target area can contain empty elements located at 0,0 with zero size.
If we hit such combination the drop element is placed at 0,0 and we don't consider other valid elements located at negative positions.
That leads to incorrect drop target indicatop placement; it's located at 0,0 coordinates.
In this patch we ignore empty elements and iterate through valid ones only so we correctly place drop indicator even when screen coordinates are negative.
Differential Revision: https://phabricator.services.mozilla.com/D159698
