Previously, the tabindex attribute wasn't supported on non-control XUL elements at all.
The only way to make those focusable was to use -moz-user-focus: normal.
However, that caused the element to be included in the tab order; there was no way to make it focusable but not tabbable.
This can now be achieved using tabindex="-1".
This will primarily be useful for buttons on toolbars, which will be grouped under a single tab stop for efficiency.
For consistency, this also changes the behaviour of tabindex="-1" with -moz-user-focus: ignore on XUL controls.
Previously, -moz-user-focus: ignore would override tabindex="-1", making the element unfocusable.
Now, the tabindex attribute always overrides if explicitly specified.
Differential Revision: https://phabricator.services.mozilla.com/D12000
--HG--
extra : moz-landing-system : lando
This also adds a js::ClassOps variant, js::DefaultGlobalClassOps which can
be used in js::Class.
Depends on D11569
Differential Revision: https://phabricator.services.mozilla.com/D11570
--HG--
extra : moz-landing-system : lando
The modification to nsLayoutUtils::GetFirstLinePosition() is needed because we
need to get the correct first line position from child (i.e. ColumnSet) when
there's an outside bullet on ColumnSetWrapperFrame.
The difference between the two newly added tests is "overflow: hidden" on
the columns.
Differential Revision: https://phabricator.services.mozilla.com/D7009
--HG--
extra : moz-landing-system : lando
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
This makes a few small but significant changes to the logic breakpad uses to
merge module memory mappings:
- First of all we merge areas of reserved space if their offset is either 0 or
the end of the previous non-reserved mapping.
- Whenever we encounter an executable mapping we flag all the merged modules
as executable. This shouldn't happen but apparently some older Android
linkers suffered from a bug that caused the first mapping not to be
executable.
- Last but not least we record the raw end address of a module on Android.
This shouldn't affect us but it's done in upstream breakpad so it probably
doesn't hurt.
Differential Revision: https://phabricator.services.mozilla.com/D12113
--HG--
extra : moz-landing-system : lando
Although the methods of Matrix3D in animated_properties.mako.rs could be
simplified by mako, it's a little bit hard to read because they are far
from the usage and definition. Therefore, we move them to the definition of
computed::Matrix3D and expand the mako.
Depends on D11935
Differential Revision: https://phabricator.services.mozilla.com/D11961
--HG--
extra : moz-landing-system : lando
We manually implement ComputeSquaredDistance for Translate, Rotate, and
Scale because we have to handle mismatch cases, and actually we don't
need to implement it for specified types.
Depends on D11934
Differential Revision: https://phabricator.services.mozilla.com/D11935
--HG--
extra : moz-landing-system : lando
Basically, most of the animation code of transform don't need mako, so
we could move them into values/animated/transform.rs.
However, we still use mako to generate some code to make the methods of
Matrix3D simpler, so I still leave them in animated_properties.mako.rs.
Depends on D11933
Differential Revision: https://phabricator.services.mozilla.com/D11934
--HG--
rename : servo/components/style/properties/helpers/animated_properties.mako.rs => servo/components/style/values/animated/transform.rs
extra : moz-landing-system : lando
I'm trying to put all the mako code together, so we could move transform
code into a different file.
Differential Revision: https://phabricator.services.mozilla.com/D11933
--HG--
extra : moz-landing-system : lando
The first comment appears in ReadableByteStreamControllerPullSteps. It's OK to
delete it because we just asserted that there are no pending read requests
(step 3.a.).
The second comment appears in JS::ReadableStreamUpdateDataAvailableFromSource.
It's OK to delete this one because it's in the hasDefaultReader branch. Default
readers don't have read requests that care about the number of bytes available.
Differential Revision: https://phabricator.services.mozilla.com/D12111
--HG--
extra : moz-landing-system : lando
ReportArgTypeError is replaced with a new helper function template,
UnwrapAndTypeCheckArgument. The old function used the expression decompiler,
but that seems unhelpful here; the new code uses InformalValueTypeName on the
actual argument value.
Differential Revision: https://phabricator.services.mozilla.com/D11684
--HG--
extra : moz-landing-system : lando
Each patch in this stack deletes comments that are redundant with the new
naming convention.
In ReadableStreamTee_Cancel, we have a variable named `unwrappedReason` whose
purpose is to create a properly wrapped verison of `reason`. It's a little
vertiginous. But I think this is what the new convention demands and it's not
so bad.
Also in ReadableStreamTee_Cancel, step 4.c., we wrap `cancelResult`, which does
not have an `unwrapped` tag. This is because we switched realms between the
declaration of `cancelResult` and the line of code where we're going to use it.
I think this just means the convention is never going to make all correct code
obviously-correct and all wrong code obviously-wrong. Still an improvement.
Differential Revision: https://phabricator.services.mozilla.com/D11683
--HG--
extra : moz-landing-system : lando
This renames the other CreateReadableByteStreamController signature, since the
two seem different enough to warrant distinct names.
Differential Revision: https://phabricator.services.mozilla.com/D11680
--HG--
extra : moz-landing-system : lando
They already do, as it's impossible for content to get hold of a stream with no controller,
which is the only kind of object our existing code would accept. But the spec is now more
direct, and the code should match it.
Differential Revision: https://phabricator.services.mozilla.com/D11679
--HG--
extra : moz-landing-system : lando
