Let sandbox early startup ride the trains by setting security.sandbox.content.mac.earlyinit=true on all releases, not just Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D13470
--HG--
extra : moz-landing-system : lando
This patch replace the LWT aliases with their related non-deprecated alias in all the theme API tests
that don't seem to be specifically testing the LWT aliases (e.g. browser_ext_themes_lwtsupport.js is
leaved unmodified for this reason).
The main reason to replace them in the "not stricly LWT-related" tests before their final removal
(currently planned for Firefox 69) is that the deprecation warnings will make these tests more
noisy (and so they may be making harder to investigate failures, without any actual gain in terms
of coverage).
Depends on D12297
Differential Revision: https://phabricator.services.mozilla.com/D12783
--HG--
extra : moz-landing-system : lando
This moves getting and setting the value of app.update.auto from nsUpdateService.js to UpdateUtils.jsm so nsUpdateService.js isn't loaded during startup
Changes the browser_policy_app_update_URL.js test to check the default pref for app.update.url since the default pref is read by app update
Fixes a NS_NOINTERFACE error in app update xpcshell tests for AppInfo not implementing nsIPlatformInfo
Differential Revision: https://phabricator.services.mozilla.com/D13285
--HG--
extra : moz-landing-system : lando
Previously the omnibox keyword would not allow trailing slashes, such as go/
Chrome allows this keyword, and Firefox should allow this too.
Differential Revision: https://phabricator.services.mozilla.com/D12242
--HG--
extra : moz-landing-system : lando
This adds a skipintoolbarset to the toolbar-menubar spacer and the titlebar-buttonbox-container
hbox to avoid a case where an exception can be thrown from CustomizableUI.isWidgetRemovable,
which expects all direct descendants of toolbars to either have an ID, be one of a special
set of node types, or have skipintoolbarset="true" set on it.
Differential Revision: https://phabricator.services.mozilla.com/D13147
--HG--
extra : moz-landing-system : lando
1. Add successorTabId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
Add an optional previousTabId property to the onActivated event,
which is present if the previously activated tab is still open.
Differential Revision: https://phabricator.services.mozilla.com/D9271
--HG--
extra : moz-landing-system : lando
This is a quick fix to ensure that the search install panel is shown when an extension uses is_default. The intention is to uplift for 64.
Differential Revision: https://phabricator.services.mozilla.com/D13078
--HG--
extra : moz-landing-system : lando
Removed all references to 'ExcludeReadOnlyFolders' since Firefox doesn't
(and will not) support read only folders.
Differential Revision: https://phabricator.services.mozilla.com/D12821
--HG--
extra : moz-landing-system : lando
Normally, permission prompts would define a permissionKey attribute in order
to get integrated with SitePermissions. Since SitePermissions is internally
hooked up to TemporaryPermissions, such permission prompts do not need any
extra handling for taking benefit from the temporary permissions infrastructure.
For the Storage Access API, however, we're not going to use SitePermissions,
and instead Gecko will be in charge of defining the required permissions in the
permission manager database when the prompt is responded to with an Allow
action. This means that by default we won't be integrated with the temporary
permissions setup either.
This patch allows prompts to define a new way to opt out of reading and writing
permissions through the permission manager but still being integrated with
temporary permissions. That is, through returning false from the new
usePermissionManager attribute and returning a name from the permissionKey
attribute. TemporaryPermissions will do the expected work in order to ensure
that each prompt with a unique key will be automatically blocked if a previous
instance of the same prompt type with the same key has been blocked in the
current tab.
Note that this doesn't yet include support for showGloballyBlocked or
permitTemporaryAllow since those features aren't needed for our use case.
Differential Revision: https://phabricator.services.mozilla.com/D12466
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
This changes the strings' l10n ids for the strings that changed context but did not previously change their ids.
Differential Revision: https://phabricator.services.mozilla.com/D12958
--HG--
extra : moz-landing-system : lando
Generally, this switches Services.locale.requestedLocales calls to use
Services.locale.appLocalesAsBCP47.
Differential Revision: https://phabricator.services.mozilla.com/D10980
--HG--
extra : moz-landing-system : lando
We no longer set up a listener on a per-window basis for category preference changes.
Differential Revision: https://phabricator.services.mozilla.com/D12667
--HG--
extra : moz-landing-system : lando
This also adds a skipintoolbarset to the titlebar-buttonbox-container hbox to avoid a case
where an exception can be thrown from CustomizableUI.isWidgetRemovable, which expects all
direct descendants of toolbars to either have an ID, be one of a special set of node types,
or have skipintoolbarset="true" set on it.
Differential Revision: https://phabricator.services.mozilla.com/D12592
--HG--
extra : moz-landing-system : lando
If the launcher process's parent process was ephemeral, the parent may have
terminated before the launcher has a chance to open a handle to it. If so,
OpenProcess will fail with ERROR_INVALID_PARAMETER, as the pid is now invalid.
This is a common case, so instead of erroring out, IsSameBinaryAsParentProcess
should treat this case as, "No, our parent was not a Firefox binary" and just
return false.
This eliminated the intermittent xpcshell failures on try.
Differential Revision: https://phabricator.services.mozilla.com/D12714
--HG--
extra : moz-landing-system : lando
Previously this would just clear the locales attribute on the button, but the
button isn't always part of the content now. The content is generated in full
when it is shown.
Differential Revision: https://phabricator.services.mozilla.com/D12567
--HG--
extra : moz-landing-system : lando
The URL bar is used for showing the URL, but also as a way to start a search.
A placeholder text is shown to let the user know about these possibilities.
In right-to-left (RTL) interface, URLs are forced to be displayed from left-to-right (LTR) to avoid confusion.
This creates an undesired side-effect, causing the placeholder text to also display LTR.
Following changes in bug 1449317, this placeholder text now contains both localized text, and names of search engines (such as Google), which causes a break in the bidi flow of text.
Differential Revision: https://phabricator.services.mozilla.com/D11565
--HG--
extra : moz-landing-system : lando
Change the button background from purple to blue. Stop the label from flashing white on click on mac and hover on linux.
Differential Revision: https://phabricator.services.mozilla.com/D12587
--HG--
extra : moz-landing-system : lando
This is needed because UA Widget cannot load resources from chrome://mozapps.
Depends on D11701
Differential Revision: https://phabricator.services.mozilla.com/D11702
--HG--
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/osx/global/plugins/pluginHelp-16.png
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/windows/global/plugins/pluginHelp-16.png
extra : moz-landing-system : lando
This is needed because UA Widget cannot load resources from chrome://mozapps.
Depends on D11701
Differential Revision: https://phabricator.services.mozilla.com/D11702
--HG--
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/osx/global/plugins/pluginHelp-16.png
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/windows/global/plugins/pluginHelp-16.png
extra : moz-landing-system : lando
Previously, if the accesskey attribute was missing then the label would reach up
to binding parent to find it's accesskey. In practice, bindings already do
[xbl:inherits=accesskey] to send it down to the label anyway.
The problem with this is that for controls without accesskeys, the attribute doesn't get set,
so the label will access the control from JS. This is fine for XBL, since typically
the label XBL will construct at the same time as the control, but when migrating
to Custom Elements, the label gets connected even when the control is hidden.
Differential Revision: https://phabricator.services.mozilla.com/D12355
--HG--
extra : moz-landing-system : lando
Generally, this switches Services.locale.requestedLocales calls to use
Services.locale.appLocalesAsBCP47.
Differential Revision: https://phabricator.services.mozilla.com/D10980
--HG--
extra : moz-landing-system : lando
The search handler was being called when focusing the menuitem with the keyboard on Windows. This didn't provide a good experience and left the popup open once the search started. Ensure the popup is always shown when using the keyboard and don't trigger the search until the popup is closed.
Differential Revision: https://phabricator.services.mozilla.com/D12324
--HG--
extra : moz-landing-system : lando
* New AddressForm instances for each address type
* Move selected-state-key out of state for the address forms, and into an attribute
* Remove passing form title via state, just use data-title-edit and data-title-add on the element
* Remove shippingOption form title logic from address picker, just set the right attribute values from PaymentDialog
* Move setting the extraRequiredFields data attribute the payer form needs out to the payment-dialog's render.
* Amend onboarding logic to direct to billing address form when necessary
* Fix-up tests
Differential Revision: https://phabricator.services.mozilla.com/D11545
--HG--
extra : moz-landing-system : lando
Currently, some "input" event dispatchers in our script dispatch "input" event
with UIEvent. This is completely wrong. For conforming to HTML spec, Event
is proper event. Additionally, for conforming to Input Events, InputEvent
is proper event only on <textarea> or <input> element which has a single line
editor.
For making us to maintain easier, this patch adds new API, "isInputEventTarget"
to MozEditableElement which returns true when "input" event dispatcher should
use InputEvent for the input element.
Finally, this makes some dispatchers use setUserInput() instead of
setting value and dispatching event by themselves. This also makes
us to maintain them easier.
Note that this does not touch "input" event dispatchers which dispatch events
only for chrome (such as URL bar, some pages in about: scheme) for making
this change safer as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D12247
--HG--
extra : moz-landing-system : lando
Currently, a lot of code dispatch "input" event and some of them dispatch
"input" event with wrong interface and/or values. Therefore this patch
creates nsContentUtils::DispatchInputEvent() to make all of them dispatch
correct event.
Unfortunately, due to bug 1506439, we cannot set pointer to refcountable
classes of MOZ_CAN_RUN_SCRIPT method to nullptr. Therefore, this patch
creates temporary RefPtr<TextEditor> a lot even though it makes damage to
the performance if it's in a hot path.
This patch makes eEditorInput event dispatched with
InternalEditorInputEvent when "input" event should be dispatched with
dom::InputEvent. However, this patch uses WidgetEvent whose message is
eUnidentifiedEvent and setting WidgetEvent::mSpecifiedEventType to
nsGkAtoms::oninput when "input" event should be dispatched with
dom::Event because we need to keep that eEditorInput and
InternalEditorInputEvent are mapped each other.
Differential Revision: https://phabricator.services.mozilla.com/D12244
--HG--
extra : moz-landing-system : lando
It's difficult to create new test which checks "input" events caused by
all edit operations especially when text is inserted from our UI. Therefore,
this adds "input" event type checks into existing tests.
Additionally, this adds new test for MozEditableElement.setUserInput() whose
behavior needs to be fixed in this bug.
Currently, InputEvent interface should be used only on text controls or
contenteditable editor when dispatching "input" event.
https://w3c.github.io/input-events/#events-inputevents
You may feel odd to use different event interface for same "input" events.
However, other browsers also use InputEvent interface only in the cases. So,
we should follow them for now.
Differential Revision: https://phabricator.services.mozilla.com/D12243
--HG--
extra : moz-landing-system : lando
We should be ignoring about: URIs for the page load time metric, since they load very quickly
and aren't representative of Web page load times.
Differential Revision: https://phabricator.services.mozilla.com/D12492
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This removes the wrapping box inside the anonymous content, and replaces
the anonymous label with an ::after CSS rule that sets text based on
the [title] attribute.
Because it doesn't replicate the anonymous wrapping box with light DOM:
- Calling JS don't need to be updated (the child added via appendChild
is still a direct descendant of the element).
- Many CSS selectors don't need to be updated (if they were targeting the
slotted children as direct descendants. However, CSS selectors that were
targeting the anonymous content directly do need to be updated, since those
nodes are removed.
Differential Revision: https://phabricator.services.mozilla.com/D12172
--HG--
extra : moz-landing-system : lando
This makes it possible to navigate by headings when using accessibility technology.
Information labels displayed when removing the master password are also restored.
Differential Revision: https://phabricator.services.mozilla.com/D11792
--HG--
extra : rebase_source : 42f156dbccf074445cf7e08d8de246058437c91b
Removed comment about Firefox 27 and below since it is no longer relevant after the LZMA watershed
Changed a couple of comments for clarity
Differential Revision: https://phabricator.services.mozilla.com/D12424
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
All instances of nsIBrowserSearchService::currentEngine have been replaced by nsIBrowserSearchService::defaultEngine. Dropping this variable now.
Differential Revision: https://phabricator.services.mozilla.com/D12223
--HG--
extra : moz-landing-system : lando
Bug 1469148 added support for detecting which mouse button was used,
by synthetizing "command" events when a "click" event was captured.
The implementation did not account for unclickable menu items, such
as items that act as the parent of a submenu (see bug report),
separators and disabled menu items.
This patch adds the necessary checks and regression tests for these
scenarios to make sure that such clicks are ignored, as expected.
Differential Revision: https://phabricator.services.mozilla.com/D13084
--HG--
extra : moz-landing-system : lando
This test add a check for pointer id to make sure it always reply the
spoofed pointer id when resistfingerpritning is enabled. It also extend
the original test of pointer capture events into a test which tests
mouse and touch interfaces to make sure pointer capture events is
correctly filed even with the spoofed interface id. In addition, it also
adds test for that set/releasePointerCapture only accepts spoofed
pointer id when fingerprinting resistance is enabled.
Depends on D9532
Differential Revision: https://phabricator.services.mozilla.com/D9533
--HG--
extra : moz-landing-system : lando
This is a quick pass to weed out some obsolete tests and update others.
browser_doorhanger_installs.js still needs a more comprehensive pass to
get rid of obsolete test cases.
--HG--
rename : toolkit/mozapps/extensions/test/browser/browser_bug596336.js => toolkit/mozapps/extensions/test/browser/browser_reinstall.js
extra : rebase_source : f8af8991e98424f151c6dd8822599e20c870be08
extra : source : 36ba8ad1c6000fb3810cf0fdd1542e49e50d0963
extra : histedit_source : abdb813afb162f3dff58906def889ce50a7b512b
This pref is left over from B2G days. It is currently disabled for firefox
desktop, but not for Android. This didn't affect us until now because we
always ran Android tests in non-e10s mode.
The pref ought to be removed in bug 1306801.
Differential Revision: https://phabricator.services.mozilla.com/D12293
--HG--
extra : moz-landing-system : lando
This is the first part of hiding the implementation of nsIJSID behind the
interface added in Part 1, such that we can substitute that implementation out.
I had to make a couple of changes to fix the errors caused by the new behaviour
in GenerateQI.
Differential Revision: https://phabricator.services.mozilla.com/D2279
Previously, we had specific code to do this for the "View site information" button (#identity-box) when activated via the keyboard.
To work well for keyboard and screen reader users, all such popups (e.g. Firefox menu, Page Actions, etc.) should do this.
These are all based on panelMultiView.
The arguments passed to PanelMultiView.openPopup can include the event which triggered the popup.
We now use this to detect keypress events and focus the first item in the panel in that case.
Differential Revision: https://phabricator.services.mozilla.com/D11605
--HG--
extra : moz-landing-system : lando
Change the `<engine>.<alias>.urlbar` `SEARCH_COUNTS` keys to `<engine>.alias` as described in bug 1499193 comment 23 and later.
Differential Revision: https://phabricator.services.mozilla.com/D12038
--HG--
extra : moz-landing-system : lando
This has benefits both in terms of performance and memory usage. Aside from
the obvious savings of not loading additional JS scripts in every process,
this also allows us to move more of our expensive data collection work to a
background thread, where it doesn't risk janking both parent and content
processes.
MozReview-Commit-ID: 2A593R7bIKB
Differential Revision: https://phabricator.services.mozilla.com/D13872
--HG--
extra : rebase_source : ec634ee3a3b975809f542aa8077ad32236781452
Add a test to ensure the temporary autoplay permission is sync correctly between JS and C++ side.
Differential Revision: https://phabricator.services.mozilla.com/D11711
--HG--
extra : moz-landing-system : lando
Since temporary permissions are only stored in the front-end side, we can't know whether we have
allowed page to autoplay or not without sending a request. Therefore, we want to notify the back-end
side when the temporary permissions changed.
Differential Revision: https://phabricator.services.mozilla.com/D7011
--HG--
extra : moz-landing-system : lando
It was almost identical to the toolkit version, only missing a [customizing=true]
check to prevent drag. Since Customization only happens in browser/ we are able
to replace the toolkit version with the CUI version, and then remove the CUI version.
The `#toolbar-menubar:not([autohide="true"])` selector will fall back to the
`toolbar[type="menubar"]` selector in global.css to apply the toolkit one, so
that is removed from browser.css.
Differential Revision: https://phabricator.services.mozilla.com/D12146
--HG--
extra : moz-landing-system : lando
Haik Aftandilian
Ehsan Akhgari
Erica Wright
Dão Gottwald
Sylvestre Ledru
Razvan Maries
Andrew Swan
Timothy Guan-tin Chien
Luca Greco
Daniel Varga
ffxbld
Ed Lee
Coroiu Cristina
Bogdan Tara
Vincent Cote
Gijs Kruitbosch
Csoregi Natalia
Robert Strong
matthias
Michael Kaply
Jan-Erik Rediger
Qinghao_Jack_Song
Mike Conley
hawaiianchimp
Cosmin Sabou
Matthew Noorenberghe
Marco Bonardo
Tom Prince
Bruce
Shane Caraveo
Andreea Pavel
Geoff Brown
Ryan Hendrickson
Diego Pino Garcia
James Lee
Michael Kohler
Emilio Cobos Álvarez
Brindusan Cristian
ScottDowne
Narcis Beleuzu
Andrea Marchesini
Drew Willcoxon
Jared Wein
Nazım Can Altınova
Christian Holler
Mark Striemer
shindli
Noemi Erli
Aaron Klotz
Ursula Sarracini
yehudab
Maxiwell Luo
Tim Nguyen
Dorel Luca
Brian Grinstead
k88hudson
Paolo Amadini
Sam Foster
Masayuki Nakano
Tim D. Smith
Nathan Froyd
Tom Schuster
Mark Banner
Siddhant085
Rob Wu
Mike de Boer
Francesco Lodolo (:flod)
Tim Huang
arthur.iakab
Sebastian Hengst
Valentin Gosu
Luke Schwalfenberg
Mike Hommey
L10n Bumper Bot
Nika Layzell
Felipe Gomes
James Teh
Johann Hofmann
Kris Maglione
alwu
Collin Wing