These functions all have a single call site, and the call site clearly always
has rect in DesktopPixel units. So it makes sense to encode this in the API,
and propagate the strongly typed units.
Differential Revision: https://phabricator.services.mozilla.com/D67696
--HG--
extra : moz-landing-system : lando
This uses `rgba(249, 249, 250, 0.24)` for the tip button background in dark themes. 0.24 is the largest alpha with two significant digits that passes the WebAIM contrast check for normal text, considering that the button text color is `rgb(249, 249, 250)`. i.e., 0.25 fails. I think it looks OK, but open to tweaks.
This patch also fixes existing problems with the hover and active states for the non-selected tip button. We've been incorrectly using primary button colors for those states even when the button isn't selected and therefore shouldn't be using primary colors. It becomes more obvious in dark mode, at least to my eye. Also the problem only shows up for intervention tips, not search tips. We should use default colors for those states when the button isn't selected and primary colors when it is selected.
Differential Revision: https://phabricator.services.mozilla.com/D69139
--HG--
extra : moz-landing-system : lando
I had to reorder the fields here to make so the first field was simple to replace.
Differential Revision: https://phabricator.services.mozilla.com/D68837
--HG--
extra : moz-landing-system : lando
I had a compilation issue with making the cell header contain a scope pointer due to the Scope class not being fully defined at that point so I worked around it by reodering the fields.
Differential Revision: https://phabricator.services.mozilla.com/D68834
--HG--
extra : moz-landing-system : lando
The strategy is the same as in IonBuilder: create an OSR entry block and a second
block merging the two predecessor blocks before the loop.
This is a lot simpler than IonBuilder because we don't attempt to type-specialize
OSR values. If this becomes an issue we'll need a strategy for that. Hopefully
this will be good enough for now until we make bigger changes to how OSR and the
Ion backend work.
Differential Revision: https://phabricator.services.mozilla.com/D68975
--HG--
extra : moz-landing-system : lando
These routes are applied to all tasks except the decision task. There
is currently no validity checking in the frontend, so if the provided
routes aren't valid the decision task will fail.
Differential Revision: https://phabricator.services.mozilla.com/D67828
--HG--
extra : moz-landing-system : lando
This adds an optional routes key to the task_task_config schema,
which is a list of strings. Anything in this key is added to the list
of routes for tasks scheduled by the decision task.
Differential Revision: https://phabricator.services.mozilla.com/D67827
--HG--
extra : moz-landing-system : lando
`AlignStateAtSelection` class is instantiated outside of editor class so that
we shouldn't make each user guarantee that there is selection range
(fortunately, the putting off cost is really low).
And as far as I tested, Blink and WebKit does not throw exception when
`Document.qeuryCommand*("justify*")` is called without selection ranges.
So, this patch also prevents exception in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D68755
--HG--
extra : moz-landing-system : lando
* Add autofilledLoginGuid argument to the .idl and toolkit implementations of promptToSavePassword and promptToChangePassword
* Pass the guid of the autofilled login along to the prompter methods in LoginManagerParent
* Don't show the password visibility toggle in the capture doorhanger when the login was autofilled
Differential Revision: https://phabricator.services.mozilla.com/D68966
--HG--
extra : moz-landing-system : lando
This patch makes sure that subtree mutation breakpoints get detached when the parent element is removed.
Differential Revision: https://phabricator.services.mozilla.com/D64190
--HG--
extra : moz-landing-system : lando
Now, `WSType` is used only by `WSRunScanner`, `WSRunObject` and `WSScanResult`.
We should hide this mysterious `enum` from other classes for making other
developers easier to understand. Therefore, this patch moves `WSType` into
`WSScanResult` and share it with `WSRunScanner` with making them friends.
Depends on D68675
Differential Revision: https://phabricator.services.mozilla.com/D68676
--HG--
extra : moz-landing-system : lando
Surprisingly, each value meaning of `WSFragment::mType` is different from
`WSFragment::mRightType` and `WSFragment::mLeftType`. It uses only 3 bits,
`WSType::normalWS`, `WSType::leadingWS` and `WSType::trailingWS`.
According to the second `if` block of `WSRunScanner::GetRuns()`, the latter
2 values mean whether the fragment starts from and/or ends by a hard line.
And also, according to there, `normalWS` means the run is visible or not.
(However, according to the first `if` block, `Visible::Yes` might be set to
for empty fragment too, but I have no better idea of its name.)
Therefore, `mType & WSType::leadningWS` can call "is start of hard line",
`mType & WSType::trailingWS` can call "is end of hard line",
`mType == WSType::normalWS` can call "is visible and not edges of hard line"
and `mType & WSType::normalWS` can call "is not edges of hard line".
So, 3 `bool` members can represent all of their status. Therefore, we should
get rid of this odd use case of `WSType`.
Depends on D68674
Differential Revision: https://phabricator.services.mozilla.com/D68675
--HG--
extra : moz-landing-system : lando
Similarly, it indicates the previous content type of the fragment.
Depends on D68673
Differential Revision: https://phabricator.services.mozilla.com/D68674
--HG--
extra : moz-landing-system : lando
It means why the `WSFragment` ends by. I.e., it tells next content type of
the fragment.
Differential Revision: https://phabricator.services.mozilla.com/D68673
--HG--
extra : moz-landing-system : lando