Follow-up to 8101b6511e.
$toolbarPlaceholder.outerHeight() only needs to be added when not
using visual section editing.
Change-Id: Idc7d9d59dea9eacbb8ee584c69e6bc4798562ea1
There's nothing we can do about missing edit buttons - they are likely
being scrubbed by some script or gadget, so let's not report the error.
Bug: T314952
Change-Id: Icf778074026a24561c228cbf11e583062571d0cb
Follow up to Icd227fc54f3bc16d5ce84c419b69344ca0d21f28
Currently showing up in logs as "NaN" but logged elsewhere
so not needed.
Bug: T314952
Change-Id: I0bf0d428384aa35bd43be026d451d62a2c237267
We need to strip the protocol on both sides. This might have been broken
by Ic00b38b04ce78178c64c13bab7f1b2e4b6c5b803 in MediaWiki core.
Bug: T321437
Change-Id: I11903b767aebfdb189a8d54fbf6fb7f8ce9ffb6a
The VisualEditorFeatureUsage instrument is a candidate for migration to
the Metrics Platform [0]. The first step of the migration is to log
events both using the Event Platform directly (i.e. via
mw.eventLog.submit()) and using the Metrics Platform client (i.e. via
mw.eventLog.dispatch()).
The Metrics Platform Client can mix in additional information -
so-called context attributes [1] - based on the stream configuration.
The majority of the default values mixed into each event are already
known to the Metrics Platform Client.
Note well that the Metrics Platform client will not log an event without
one or more streams being configured to receive that event. Therefore,
this change is a NOP.
An example stream configuration is given in [2].
[0] https://wikitech.wikimedia.org/wiki/Metrics_Platform
[1] https://gerrit.wikimedia.org/g/mediawiki/libs/metrics-platform/
+/aed6738b845/js/src/StreamConfig.d.ts#31
[2] https://phabricator.wikimedia.org/T309602#7973206
Bug: T309602
Change-Id: If40fcc6cae371788b98365953218300a5c0b3ca1
... for the sampling rate for the VisualEditorFeatureUse schema.
Bug: T312016
Depends-On: I259757db0c4441a3fcfce505d5bc82dcf2acf58c
Change-Id: I4e03b442568ed695a14d280b0e8dd92e22616426
The previous implementation tried to do this, but looked
at the query string which can be set to action=edit by VE.
Bug: T318772
Change-Id: I4f0f8d52488a6b259033232afb8ea616458275de
Setting the config var then loading mediawiki.action.view.postEdit
will already trigger the notification code, so we can remove this
duplicated code now.
Bug: T240041
Change-Id: If0d1aa4e734dab7cca168e78216f229b9924bab7
This makes the "direct" client and the VRS based client
implement the same interface, so the caller doesn't have to know
which one it is using.
It looks like ParsoidHelper will not be needed if we use this approach.
Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
A lot of this just repeats what is already set by some other rule,
e.g. because it is the OOUI default anyway. Warning. This patch is a
little more agressive. I tested it on desktop and mobile, even with
MonoBook, and could not spot a different. Please do some more tests.
Change-Id: I0ee6e70f4f14c20d431643c53031d6d5b8df1aa2
$targetContainer was calculated at the top of the file,
but it's only guaranteed to be available after jQuery ready event.
Bug: T314952
Change-Id: Id5d0c71433bfc51cb7193ee1b931a7dd8a4324d9
Factor out getAvailableEditPageEditor from getEditModeFromUri
and use instead of getEditPageEditor everywhere.
Bug: T316776
Change-Id: I34bab092b829124c52f8bc0e262a9c3aa17f2c52
This means if you load the editor on a single edit tab wiki,
then press back then forward, the editor will re-open.
Bug: T316869
Change-Id: I1ea33de7d7324a53399be9155c474a14ae21dfe8
This code is supposed to be similar to the code in activatePageTarget()
however it was checking if the *link* URL looked like a veaction link,
not the view URL. It also then tried to push this.href as the new state
which was always undefined. This meant:
* If the section edit link was veaction= then nothing happened. The URL
in the address bar would get updated *after* the editor loaded by code
in DesktopArticleTarget.
* If the section edit link was edit= (single edit tab wikis) then the
view URL would get replaced with and edit URL, meaning if you browser-
backed out of the editor, the URL was stay as the edit URL.
Bug: T316771
Change-Id: Idb5e3c51a22361e0d9916d3c31444daeff310ed2
This fixes two issues:
1. .initializeAllStickyHeaderHeights() is now executed after the
.ve-ui-mwTransclusionDialog-single-transclusion CSS class is set.
This is critical because in this mode the sticky header does
have a different height.
2. We get rid of 2 references to .sidebar that should not have been
in this class in the first place.
Also bring some more calls in an order that makes sense. This does
not make a difference and is only for readability.
Bug: T315292
Change-Id: I22f6c11de8f693edb03485adcaa186bd4b283b2f
I'm pretty sure this extra call is just pointless. This "choose"
event is triggered every time a new parameter is added to the list of
parameters. But there is another code path that is triggered in the
exact same situations: the onReplacePart event handler.
As far as I remember this "choose" handler was added very early when
the other events haven't been implemented yet.
This should be fairly easy to test. The only situation where this
could make a difference is:
1. When you have a template with 3 parameters and you add a 4th
parameter.
2. When you edit an existing multi-part transclusion that contains a
lot of parameters, but the parameters are initially hidden. The
widgets are only created when you click "show all" or start
searching.
Change-Id: I59e3873a4fe6fa5a01d681fce89fbe00756ae815
This was missing when you:
* Insert a new template and select a template with a lot of
parameters.
* Same when you edit an existing multi-part template and add a new
part (Ctrl+D) with many parameters.
Bug: T315292
Change-Id: Icd281c21a1b40d8e29343fa4975e27e8d927cd15
This is only an issue when a long parameter description is collapsed.
The float is a left over from a time when there was a delete button
on the right side of each parameter label. This is gone.
Bug: T310137
Change-Id: I249f0592de9c73a07af22bd7f86241caf0207770
This makes it possible to click on "(undocumented parameter)"
to focus the input field – the same effect as when clicking the
parameter name.
This also lower-cases the initual "(U…". This is not the beginning of
a sentence.
Change-Id: Ibfa5bbaee39c2b3a4fefbcee33102b85ca3ba9c0
On mobile, tapping anything in the sidebar should only scroll the
corresponding element into view, but not focus the input field. The
reasoning is that an on-screen keyboard should only pop up when the
input field is actually tapped.
By the way, the "jump" issue in T312768 was because of the same
reason. In that case an onFocus happens before we have a chance to
scroll. Unfortunately there is no way to reverse the execution order
of these. Which is why we disabled the animation there.
Bug: T289043
Change-Id: I1c18802b8ff776fa8d9c17e3df8020354690d29f
This patch follows the audit made on the extensions to check the usage
of the "rel" attribute and check that it's compatible with multi-values.
Bug: T315209
Change-Id: Ib323736d93ea96c86f9d56599e515c9e6d72a76e
This is split off from the unfinished patch I039d6f6. This only moves
existing code around, makes use of chaining and such to make code
more compact and hopefully more readable. Methods are renamed to
reflect better what they actually do. No behavior should change.
Change-Id: I3ba538c8c77ad4455bf0f0aa821ca14feadef7cc
Note this implementation introduces some technical debt: It adds a
little bit of knowledge about what "part widgets" and the toolbar are
to the parameter SelectWidget. I think this is acceptable.
A "cleaner" implementation is probably so complicated that we don't
want it in the code, for such a minor benefit. However, alternative
patches are very much welcome.
Bug: T313703
Change-Id: I957698d58a7622cbe54bcc2ba454388ba9f09537
The edit tab should be active as soon as the editor starts loading
(to indicate it doesn't need to be clicked again, and that the read
tab can now be clicked).
Change-Id: I450c53eef64c25e9520d3868b4ecc95204644138
The .selected class does nothing on mobile, nor are the tabs visible
under the full screen overlay.
Change-Id: I14a6747f4a3274d71b7aa16b2c9b76b62a5253c2
Generally the default button margin on the parts is 24px. The only
exception are the placeholder and wikitext when they are the last
parts in the outline.
Bug: T312644
Change-Id: Ie513bf1c022b2696cc92aacbbca59ddf6e55043e
In Iebfe2e2 we already tweaked this by 1px. Turns out this was not
enough in all relevant situations. I still get random scroll events
just because I move the mouse around. Setting: Firefox, 120% zoom,
multi-part transclusion.
Bug: T312926
Change-Id: I475c1ef029e9721cc663881e40547730389cd26d
* Rename method because it turns out it is not only about the sticky
header, but also relevant when there is no header.
* Move some code to more appropriate places.
* Use 0 as documented in OOUI, not null.
* Set the padding back to 0 when the sticky header is not visible.
As of now this is an unreachable state because the filters never go
away after they have been made visible. Still this code was always
written with this possibility in mind to make it future-proof.
* Performance optimization for the boolean "show filters?" check.
Bug: T312926
Change-Id: Iaba08ccd8bf00360fd26f9268d5be43df4f4fbd8
This is a partial revert of Ide45141. Now the scrolling always
happens (again), but properly considers the presence of the sticky
header. It was also not correctly initialized on construction time.
This is a candidate for a backport. The patch is intentionally as
small as possible because of this. Code cleanup will be done in a
later patch.
Bug: T312926
Change-Id: I06425b42566bfb2087846636055ee75e98a05029
The message was also shown when a documented template appears as
part of a multi-part transclusion but with zero parameters being
used. You see the filters in this case and can click "show all".
The message is just wrong in this situation.
Bug: T312926
Change-Id: I8d26ceec483e05fd1f69013e506fa1eb4e4c29ed
Currently the sticky size is exactly 114px. With 115px you also can
see an auto scroll effect on multi part transclusions when you hit
that 1px sweat spot at the top of the list.
Bug: T312926
Change-Id: Iebfe2e2c6360c650755cd985157949a26a5287a4
Introduced via Ibc56abf. But the OOUI SelectWidget does have some
methods for this already.
This patch also updates some @mixins documentation.
Bug: T302965
Change-Id: Iffbb44d41586786a2165f8d7916f94a52ad19122
The rename in I5a16ab4 was done the exact same time a new usage was
introduced via Ibb717ca. Neither patch shows a conflict. Still there
is one.
I remove the extra `|| null` line because it is just not needed. We
don't need to set the property to null when it was already null.
Bug: T312213
Change-Id: Id3f025786c9412e8c1946434113c41356da08098
Previously we could log a warning if the user had the editor enabled,
but the page did not support being edited as wikitext.
Bug: T312632
Bug: T314171
Change-Id: I647cb057ed44c155b4eba1b728d6908f8a7abb69
Instead of the template that's currently selected. That's confusing,
e.g. when you click one of the search fields, search for a parameter,
can't fine it, and press ctrl+shift+d to add an undocumented
parameter. Or you navigate the list of parameters with the cursor
keys, can't find the parameter you are looking for, and press
ctrl+shift+d to add it.
Still falls back to the selection when the focus is outside of the
sidebar.
We suggest to merge this before UX review, and review it later in
demo time. It's easy to undo if necessary.
Bug: T313388
Change-Id: I9848dd0af4fe821526dafc18bbd7cb1ab0e68cfc
This is send as an associative array. Instead of adding elements that
are null we can just not add them.
Bug: T291729
Change-Id: I28d847941eec865cb255779534eca14ec88f588f
Log a client error when VisualEditor cannot load because of an
incompatible skin (which is not supposed to happen in practice).
Bug: T312632
Change-Id: I2ccfaa584d7a05e10170a66d446bd4e476dcc775
Depending on the order in which this code executed, sometimes the
dialog initialization would overwrite the readonly state set by item
initialization.
They should simply all check both conditions.
Change-Id: I6a18f1e074f118423438c017b3e4e34e75579e5d
This code was for when the dialog had a trash can icon for every
parameter, and parameters could actually be deleted. It's unreachable
now.
We missed this when removing the old workflow.
Change-Id: Ic94df506ea84009a1e1863a4e9847a70498df448
OOUI support for multiple modal window managers is hacky, and only
works correctly when the managers are attached directly to <body>.
Remove the wrapper that doesn't seem to be necessary.
Bug: T313690
Change-Id: I4134c0f50d28a364dcf15b426bd9b59a4f7a985d
The dialog is unusable when there is no outline. See T313489 for a
longer explanation.
Bug: T313489
Change-Id: Ib2cc9c363d3596a16f6f1c4aef03ca216abf6b1f
Apparently this can be undefined when Esc is pressed. Note this code
cleanup related to but does not fix T313690.
Bug: T313690
Change-Id: Ia4658f8e00a68ed4cc3a6ddb0a932b3218b813dc
The need for something like this was anticipated in
I2bf43c7e83283f43e047229eb53c244918fcbb0c.
As of version 2.5.0 of Parsoid's output, if alternate text is missing
for an image but a caption is present and image isn't displaying the
caption (ie. it isn't a thumb or frame), then the text content of the
caption will be set as the alt attribute. Parsoid will then drop the
alt attribute when serializing if it matches the caption text, since
it's unnecessary.
However, if the caption is modified and the alt text isn't, the alt will
be serialized. This is likely to be unexpected to editor. They may
have missed that the both the caption and alt are populated in VE and
only edited one place.
Since all of the above is happening only for images where the caption
isn't visible, it doesn't appear to be a much used feature since, at
least for inline images, the experience of caption editing was already
less than optimal.
However, because of a quirk in how galleries are rendered in Parsoid,
this affects gallery caption editing, which is visible and presumably
used more often. See T268250 for a discussion on an improved gallery
structure. But for now, gallery images are effectively inline and set
the alternate text, thus subject to the above.
Here we add a checkbox so that the default is to ignore the alt if it's
the same as the caption. And only make use of it if it differed
originally or was explicitly unchecked to modify.
Bug: T311677
Change-Id: Idf297d8a98995971c5835b0cea56c3317a3626e2
Turns out we have two concepts, now represented by two methods:
1. A top-level part can only be moved or removed when it is actually
selected. This is relevant for the toolbar buttons and for the
keyboard shortcuts/hotkeys. We intentionally block the buttons
and hotkeys when a parameter is selected.
2. Adding a new part or parameter is always possible, no matter if a
top-level part or parameter is selected. This is again relevant
for the toolbar buttons and hotkeys.
Bug: T313388
Change-Id: I17caf8fce9d8f1ebe21660cf8c6d91ace8423490
Same issue as in the previous patch, but less intrusive. It was always
possible to add a new part, but it was often inserted at the wrong
position. It worked only as intended when a top-level part was
selected. When a parameter was selected, the new part was always
appended to the very end of the transclusion, not after the selected
template.
This is now a little bit of duplicate code. We might extract this to
a method in a later patch.
Bug: T313388
Change-Id: I1327222969d1d315bdacf3998f366d88c4c26bd5
The hotkey was only working when a top-level part was selected, not
when a parameter in a template was selected.
Some outdated helper methods are now marked as deprecated. They will
be replaced and removed in later patches.
Bug: T313388
Change-Id: I5ffe45fd00c36b97ee36dc0ba6831db5a941c731
This is a partial revert of Iaf089f4. It restores the old behavior:
* In case there is already a highlight in the parameter list, just
keep that. Usually there is no highlight at this point, but better
have this check in place to be sure.
* Otherwise always start at the top.
Jumping to the selection is confusing, esp. for keyboard-only users.
The argument goes like this:
* Let's say I'm in the middle of editing values on the right side of
the dialog.
* I want to navigate to the sidebar. How do I do this with the
keyboard? I use the tab key.
* Pressing tab also implies I move the selection to the next
parameter. And the next. Until I reach the end of the parameter
list. Then the selection stays there.
* When I finally reach the sidebar and tab into the parameter list,
the last parameter is selected. But this was merely a side-effect
of me navigating the dialog.
Such a "selection becomes highlighting" behavior was not specified
in T311204.
This patch is requested and approved by PM.
Bug: T312647
Bug: T311204
Change-Id: Ie5b5dfd4fca132050815e6182845ca23adb5f805
This should make zero difference in most situations. Except you
navigate a list of parameters with the keyboard. In this case the
SelectWidget gets a dark blue outline which overlaps with the light
blue selection bar, but the outline disappears behind the bar. This
looks odd. Making the color transparent fixes this without the need
to fiddle with z-index or such.
Bug: T311204
Change-Id: I7049eb60dc0ea72c2c4620f4351525fe447e0f46
The main motivation is to get rid of the vague method name
"setParameter" that was previously used for three different methods
in three different classes. Now the three methods have three
different names.
Change-Id: I938de30b368daf6ce3385b2ed2bca98f316593e1
We would love to name this state "selected", but that term is already
used for a template parameter that is checked/used. The idea of "set"
was to have a list of parameters where one is "set". But the word is
confusing. I suggest "active page" because the entire purpose of the
blue selection is to highlight the currently active page (i.e. the
one you currently interact with on the right side of the dialog) in
the sidebar.
Change-Id: I5a16ab4c193ea05c21bb3bf89ada2ef550d8d6bc
I hope this makes it a little more readable. The two steps done in
the loop are mostly independent:
a) Find pages that should be removed.
b) Find next best top-level page when the current one is removed.
Change-Id: I600253fb206a31ef5851865e733b66c336d5014d
This does not have much of an effect, but can cause visual glitches
in rare situations. One goes like this: Use the keyboard and tab key
to navigate to a list of parameters in the template dialog. Press
space to enable the checkbox. The parameter gets a blue background
(= it's now the active a.k.a. "set" item). Press space again. Blue
disappears, as it should. Press space again. Blue is now missing.
Bug: T312213
Change-Id: I3071ec4d0a05e3505ec5216acc5a97b8eaf6f5d5
1. Before, removePages() was calling setPage() with null. This makes
sense for removed top-level parts because these are really removed
from both sides of the dialog. Template parameters are never removed.
Only unchecked (and removed from the right side of the dialog, but
this is not what this code is about). When I navigate a parameter
list and uncheck a parameter I need the focus and highlighting to
stay.
2. We have a dedicated method when a parameter is unchecked. This
can check if the removed parameter is also the selected one (called
"set" in this code) and can reset this state. Without losing the
highlighting or anything else.
Bug: T312213
Change-Id: Ibb717ca49cae805617ebee196937c79daa72f1c1
There are many errors that are temporary in some way, and treating
them as unrecoverable is a poor experience.
Even for errors that really are unrecoverable, our interface works
poorly, because you need to hide the error message first to do
anything else, and you need to close the dialog to see it again.
This distinction is not really helpful, let's get rid of it.
Bug: T307330
Change-Id: I9680cc416da5b27881aeb3502f506dcb5d4bb71f
Optimization: Don't search for a checkbox that represents a not yet
named parameter placeholder. There is never one.
Fix: Store null, not undefined.
Bug: T312213
Change-Id: I395008f15d13133ad456d0a77571b7aa1c7a7fc9
Steps to reproduce:
* Set a breakpoint or debug.log() at the start of
TransclusionOutlineWidget.setSelectionByPageName()
* Edit a multi-part template.
* Use the keyboard to navigate to a template name in the sidebar.
* Press space.
This is currently triggered twice. Let's get rid of the more obscure
one. It was introduced as part of Ic4ee673. I don't really know why.
Bug: T313207
Change-Id: I3ddc072f5d42c17249abc82026e0bf1a4be1dc6e
This also means we have to move the declaration/documentation of the
event up one level into the generic "part" widget.
Change-Id: I1b803201f8955b58136ee7f37c04c01edcd47395
The code that receives this event does not need to know that the
source is a "parameter". It's just some "item" in the sidebar. The
idea is to reuse the event for both top-level parts as well as
parameters. This will be done in the next patch.
Change-Id: I858040f5adf8e156b6013caaa527b3237b7bac0f
What I found is a single `$container.animate( animations )` that's
responsible for the misbehavior described in T312768.
This method is called from a few places. I think none of these places
benefits from making this an animation. This is often more distracting
than helpful, especially when navigating with the keyboard.
Bug: T312768
Change-Id: I90a80d6ae8c1b47ee22297d2520255cad890b90e
Fix setParameter() and let it (un)highlight parameters independent
from a selection (called "set" here).
Bug: T312925
Change-Id: Ie4e9ba94659f4f70160193ca6bec804f8a4473e4
These comments just repeat what the code says. Most of them are
copied from OOUI. Some talk about BookletLayout – a class name we
don't use any more.
Change-Id: I7ce354dfe059657395103ffef767eb8f6d37bfb7
Note how the two-pane layout was already handling the two events
identical:
sidebarPartSelected: 'onSidebarItemSelected',
templateParameterSelected: 'onSidebarItemSelected'
We move this knowledge up one level into the sidebar. Both actions
now trigger the same event.
This implies that we are now using the event formerly known as
"sidebarPartSelected" to act on both top-level parts as well as
parameters. We reflect this by renaming it to "sidebarItemSelected".
Change-Id: I9a2c95f91f05de7312d38ec4c8b360141a0c447d
The optimization removed in this patch is done twice. The effect is
that the loop does not end when it finds a match but the match happens
to be the current page.
This doesn't change anything. It's really only about performance.
Change-Id: I5c2de101eb2f14f814f00cf7eacf46b70346f4c8
This is not only fired when a parameter is added. It's also fired
when pressing spacebar on a parameter that already exists.
Change-Id: I245aa9f5938eb38c3a3f224a4d642d57068cf23b
This is not only fired when a parameter is checked or unchecked.
It's also not only fired when another parameter in the parameter
SelectWidget is selected. It's always fired just because the
spacebar is pressed. This is so we can scroll that parameter into
view.
Change-Id: Id621405b7ca3116cd4a06f474e49776d0830dccc
This line was added as part of I0229b63. While what the comment says
is still true to some degree, the line stopped being helpful when
we introduced sticky headers. When scrolling the sidebar for a
multi-part template with many parameters the sticky header jumps up
and down by this 1 pixel.
TL;DR: This is one of these hacks where it's better to remove it and
look for a better solution when we notice the original issue again.
Bug: T312768
Change-Id: I2fedea4e1d4d6c95c74a63c522821a6ebc2ee2b2
250ms gaps are pretty common when typing at a normal speed, resulting
in a lot of (often expensive) API requests (e.g. T312319). For most
use cases this level of responsiveness in the preview is not necessary.
Change-Id: I6504567d4da02a66171ee35a9c4fd35c85136909
This patch contains a small cleanup that moves the scrollIntoView into onSidebarItemSelected.
Since all other places already have a focus call, scrollIntoView is not needed there.
Bug: T312850
Change-Id: I1a3cb3905faea2bd8a6bf8dc4cfd748813e1c875
This regression from Iaf089f4b271fd853b17c1aa7f5938510ea8f5431.
Not calling the parent here was is essential, because when clicking
the checkboxes this event will trigger the focus of the whole widget.
That's not what we want in this case though. Also it seems we don't
need any of the logic from the parent and can get rid of that
complexity.
Bug: T312855
Bug: T312856
Bug: T312924
Change-Id: Ib3a2eeeb6d519dfa1bb627049f6b3a4708017e86
Using Parsoid HTML in the 2017WTE has enabled us to iron
out lots of rendering bugs over the past few years.
In that time Parsoid has been moved into PHP, and at some point
we also become the default parser.
Also more extensions have started to use content transform hooks,
which are only supported by the action API.
As a result it now seems like a good time to migrate back to the
content API instead of building the preview from Parsoid HTML.
Bug: T154844
Change-Id: I90d775dd71d5f5a61d651b63d946ab60a27e2ca3
Fixes a bug that crashes the interface when unsetting the focus after
another input was focused, because `page` is undefined in this case.
We were already calling `setPage` to unset focus, so document it.
Bug: T312017
Change-Id: I2926beffe23e0ee822f5690d4791534a5413886a
This can only happen when deleting the last part of a transclusion,
then we want to set the previous page as selected. This should never
be a parameter though.
Bug: T312221
Change-Id: I06700dcf37f6d4f7dd073f8f2bc1b8b0a17a62c4
Just putting this eslint auto fix out there. No hard feelings, but
a warning that pops up everytime.
Change-Id: I157e0338e5f5a6f27dbbd9ae116da0f922468586
Triggers scroll in all situations where highlighting changes.
Including keyboard navigation.
Bug: T312542
Change-Id: I849f64c5cefe0cac3fde6e848b23b7b0cfc489ce
Introducing a set method to have a different state for a set
parameter and a highlighted one in the selection.
Allows us to remove a lot of workarounds for missusing the
highlight state and fixes several issues with these workarounds.
Main implications:
- Keyboard navigation and mouse hover now sets the grey highlight
- If a parameter is set (blue highlight) keyboard navigation returns
when focusing the SelectWidget
- If nothing is set keyboard navigation starts at the top after focus
- Unchecking a parameter using space will not influence the keyboard
focus in the list
- Highlighting a parameter with the mouse lets keyboard navigation
continue from there.
Bug: T312647
Bug: T311204
Bug: T312213
Depends-On: I385dca1d95033961d3844e888521750443e49c95
Change-Id: Iaf089f4b271fd853b17c1aa7f5938510ea8f5431
