They fail on win7 only with my patch for bug 1805694 (tried win 10 with
and without native menus and nothing, sigh) and I need to debug them.
Let's do this while at it, this makes the test run on macOS and Linux
too, since browser_selectpopup is sadly disabled on those platforms.
Differential Revision: https://phabricator.services.mozilla.com/D164951
Make Places views constructors arguments more coherent, passing the root
and view elements up to the super class explicitly.
Remove the options argument, that was not strictly necessary, the same info can
be obtained directly.
Rename the "builder" attribute to "afterplacescontent" to clarify what it is
and make panel use it, instead of passing an insertionPoint option.
Additional cleanups:
Make chevron and BMB menus use coherent popupshowing observers.
Remove useless .viewElt accessor, .associatedElement can be used instead.
Avoid an access to the private _rootElt property from the controller.
Differential Revision: https://phabricator.services.mozilla.com/D164827
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
Since macOS fullscreen can handle incoming fullscreen requests during a
fullscreen transition, it is no longer necessary to check for
visibilitychange events, which are also no longer fired during these
tests.
Differential Revision: https://phabricator.services.mozilla.com/D164247
I was unable to get gnome searching working at all on my machine (perhaps it's broken on Ubuntu?), thus I was unable to verify this fix myself -- but it seems pretty straightforward and safe to take.
Differential Revision: https://phabricator.services.mozilla.com/D164902
This adds the <moz-support-link> custom element as well as stories and
tests for this reusable component. The purpose of this component is to
replace individual implementations of the "Learn more" links present
in Firefox, specifically in about:preferences and about:addons.
See Bug 1801927 for an instance of using this component to refactor
the "Learn more" links in about:preferences#general.
Differential Revision: https://phabricator.services.mozilla.com/D164131
`.footer` is no longer used on extraClasses, so I got rid of that.
I simplified the `.entry` bits because they were unnecessarily
verbose. Honestly I think we may be able to remove the getter/setter
for `options` entirely, but I got bored of trying to modernize things...
PlacesPanelMenuView was introduced in bug 963095 and then replaced
as part of Photon (with PlacesPanelview) and then I removed the only
callsite (that was already behind a pref) in bug 1354117, so that was
just dead code, AFAICT, so I removed it.
Differential Revision: https://phabricator.services.mozilla.com/D164757
Only the bookmarks menu button is doing this peculiar re-using of
options.
I tried various fixes: keeping the inheritance but replacing only the
rootElt/viewElt (and using Object.assign to clone the options so modifications
don't 'transmit' to the ancestor menus) but it was messy and net code increase
for a pretty crufty UI surface. I also wasn't sure if that would end up
negatively influencing (now or in the future) e.g. menus shown from the main
bookmarks toolbar view (which would show up as a 'parent' view for the menus
we open from there), and thought that reusing the options was likely to cause
further confusion in future as well, should we add more, uh, options, to them.
So in the end I stuck with Keeping It Simple - I just repeat the one-off
repeating entry class. I'm not even sure how needed this is - in particular,
I wonder why we don't need it for other submenus for 'real' bookmark folders!
But I didn't investigate this too much. If you're sure that we can get rid of
some more of it, happy to do that in a followup.
Note that the addition of _init() was not ultimmately needed to fix this bug
(I think), but it brought the initialization sequence and when we set
`_placesView` more in line with what we did before and what I already did for
`PlacesToolbar`, so that seemed like a good thing to avoid further/other issues.
Differential Revision: https://phabricator.services.mozilla.com/D164756
ko -> db333ef72402fa056b88e475cd49539189bd523c
lo -> bd0abf9dbc00130cfc2323c85ba6787df8553ac2
pa-IN -> 2b8bbb10362677eb2cbc85747e16122aaf88a40c
sr -> cbd90b6da6611e9914fc2222480dab7aa445fc06
sv-SE -> 5a9d0900196108e2bab4a49b75a8d67a5c3553fe
uk -> beb2f89c71898080b59566424405c5673a47fc2b
This stops selecting buttons on mousedown so that selection and the input remain
in a sensible state after clicking the block button while top sites are showing
(e.g., in the weather suggestion).
This turned out to be surprisingly complicated, so please see the bug and code
comments for details. I think our selection logic is pretty brittle or at least
convoluted and could stand to be simplified, but I didn't want to make large
changes here. Ideally we wouldn't treat buttons any differently on mousedown --
so we'd select them too -- and it may be possible to do that while avoiding the
problems I talk about in the bug, but I don't think it's at all worth the
complexity that seems to be required.
I added a new task to the test Daisuke created in D155812.
Differential Revision: https://phabricator.services.mozilla.com/D164018
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
This adds checks to the main sponsored and nonsponsored tests to ensure we have
test cases where this value is both true and false. I think it's important to
have test cases for both sponsored and nonsponsored suggestions since these are
the two main types of Firefox Suggest suggestions. I don't think it's necessary
for other types of suggestions because they all use the same logic, so if these
checks pass for sponsored and nonsponsored suggestions, we can be reasonably
sure other suggestion types are handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D164617
be -> c9a4a87766bfda42bdf42e58b002c2c3a7f0d176
fur -> 4dd12467f339cf7878ef26ce47e9869ce3bab612
he -> b8ecafd106e6e4ce66c06e4e3bb78058e4e38f66
ia -> 92ff3faa1014399b42f315f50b38bd52111e1440
it -> 36793dd60782d599e52ae9863a7b37a8118880e3
kab -> 39c55585541b19a511571e5ecd82444487eaf527
kk -> cecde95350bfa0fa313d1df6ecf52e02e7494942
lo -> 1d5b2dcd31a2f4b4c6764373cb8d1b0d81637e5c
pa-IN -> 220dc6c90cc84ead0f39b6d5f74c8e17bcb6e5cd
th -> a5e83e9739b57190d248bc87e820dc61ad94a87a
Technically we could still run these tests on the non-langpack parts of the MSIX package -- but ultimately these are the same files as in the win32 build, so it's probably not worth the effort.
Differential Revision: https://phabricator.services.mozilla.com/D164674
Our own updater is disabled when running out of an MSIX build, and we hide update related things from preferences because of that.
Differential Revision: https://phabricator.services.mozilla.com/D164671
