The double result creates more confusion that it clears up,
and now that the query input is always used for text insertion
it is less of an issue that we don't have a case-exact match
in the results list.
Bug: T230819
Change-Id: I58cbe740fa7d0327aadd5dd111161bb7087a4ddb
New changes:
77076f828 LinkAnnotationInspector: add a "label" field on mobile
Local changes:
* Updates for mobile link label editing
Bug: T229431
Change-Id: Ib0489f6f59b228ebc4a20f7a0a515be938a8f6d3
A @method annotation is only necessary when the docblock is not
directly followed by a function declaration (in which case JSDuck
assumes it documents a property), e.g. when defining an abstract
function or referencing a function from another library.
I verified that JSDuck generates exactly the same output before and
after this change (docs/data-<hash>.js files are identical).
Change-Id: I7edf51a8560ab9978b42800ab1026f0b5555c3bf
New changes:
62f06382c Localisation updates from https://translatewiki.net.
5fc25c0d9 LinkContextItem: Apply ellipsis directly to link
Local changes to fix link ellipsis styles.
Bug: T230267
Depends-On: I25bb4fa9b7288232b08bab9c88f281817a26d6bb
Change-Id: I8a4b04d45979a1f6c375a7c92a340e3e81d7753c
The .oo-ui-popupToolGroup-handle styles only need to apply to the
editTools toolbar, where they override OOUI styles so that our
"stretched" toolbar works; they don't need to apply to the pageTools
toolbar, which contains just the editor switcher, and where they make
it look different from the MF wikitext editor toolbar for no reason.
Change-Id: I21315b34be0a7c3938f84ada720ff5754d953879
We were incorrectly always adding action=edit to the URL in that case.
The condition was always passing because `this.section` is `null` when
unset, but `this.currentUri.query.section` is `undefined` when unset.
This is a similar fix/bug to a68cc38b22.
Bug: T209163
Change-Id: Ic80ac377b763aea53678c4209ba6b3a6ba2996c9
As detailed in T95850#5078990, Parsoid incorrectly converts HTML to
wikitext when a link `href` refers to an interwiki page and contains
percent-encoded colon characters ':'. VisualEditor doesn't know
anything about interwiki pages (it treats those links as normal local
links, and expects MediaWiki and Parsoid to handle them specially),
so we can't easily special-case them. But since leaving the colon
unencoded is valid for all links anyway, we can just do that.
Bug: T103635
Change-Id: I87d7e6952983a72d90ea739b0bc8488d9f6a9be3
New changes:
854a1fa2c Distinguish active link styling
Local changes:
* Pull through active link styling
Bug: T228220
Change-Id: I925f88d32a514a749b96f501a211003bc4c924f0
New changes:
28aea2e4d Edit cards v2 design
739017973 Track usage of the new "close context" button
Local changes:
* Edit cards v2 pull through
Bug: T222396
Change-Id: I1ca885e8d8127e7827a059755315ed789a7b9210
Since we're inside the Target instance, `ve.init.target` refers to
this object. Some of the code I'm changing even uses `this` instead
of `ve.init.target` on the next or previous line.
Most of the mistakes are a result of mass search-and-replace changes
(478b0bcb, e1a887cc), or moving the code from other classes (d294006d).
But I can't explain the "ve.init.target.getSurface().getDom()" line,
it would be good to figure out why it was this way before we change it.
Change-Id: I0d7c6a48369242d4c99620fcd775ab537420d84a
New changes:
a06204317 Fix TableNode unit test getOffsetFromCoords failure on Firefox
dfe0eb025 Refactor mobile context logic into ve.ui.MobileContext
Local changes:
* Pull through for edit cards refactor
Bug: T227532
Bug: T228767
Change-Id: I6c043e039fbef62a56f475b0dc365e171ab7bf59
New changes:
1a7460058 Remove ve.newMobileContext feature flag
Local changes:
* Remove ve.newMobileContext feature flag
Change-Id: Ia8def997b7cba4623866080752b06068d2118cc3
We also show this dialog on the old wikitext editor, where
ve.init.target is not set, because the relevant code is not loaded.
Follow-up to 478b0bcbb9.
Similar to e88cd81f94, which fixed the
same issue in a different file.
I checked all uses of ve.init.target in files under ve-mw/init/ and I
think this was the only remaining mistake.
Bug: T228684
Change-Id: I15551870cdb01d570e24ba9668e67330b8072e01
Our overlay could be higher than the viewport, allowing the viewport
to scroll again.
Bug: T212159
Change-Id: I1e97d1963b214fc7673c33ae6c14ab7b0b80f31d
Since I7f6fd7ee9 it is now possible for the options bar to be
completely empty if the user is logged out. In this case hide
it and only show it again when the character limit needs to be
show.
Ideally we wouldn't have the height change, but it is quite rare
that a user gets to 400 chars and is logged out.
Bug: T228165
Change-Id: Ifbdf352afcbf4e549889e04fdb70fd30ce233aad
Turns out we had this message lying around unused,
so use it (even though an invalid title is quite
hard to come up with).
Change-Id: I0200678820fe88a59869f7fad8f491b4c5b77482
There are cases where the page title and the real/desired page name
are not the same. Fixing that also fixes the suggestions that appear
in dialogs (see related bug).
Bug: T193132
Change-Id: Iafa84c05bea08ebb061ee6d1323eb50945b39815
When previewing/reviewing changes, the "Return to save form" button
now replaces the "Resume editing" button in the top-left corner (and
receives the 'back' flag). Effectively, you tap 'back' once to go back
to the edit summary, and twice to go back to editing. This seems to me
like a much more natural interaction than two separate buttons.
Bug: T225021
Bug: T227049
Bug: T227857
Change-Id: Id27ccf06923c8aa86b1c1a9292bc43bb825ce6c8
