A previous comment said design token "background-color-interactive" was
unsuitable for the given context, so using "background-color-neutral"
design token instead.
Change-Id: I614369dcb402fdd7368be5996f3bb9720ad780b5
Replaces hardcoded CSS colors with Codex design tokens
for the purposes of improving dark-mode support.
These changes resolves issues where text was
illegible in dark-mode (white text on white background).
Bug: T367362
Change-Id: I6314c8013839ac1e9a67178be7d1cb4bc45a3321
In general, floating elements use a subtle dropdown
e.g. "Return to reply" button in DiscussionTools.
Change-Id: If3363557e3f85bbb3000b75e98d5130be1017e2f
These buttons can appear in any order depending on when
the code loads. Remove the default OOUI button negative
margin.
Replace group padding with margin now there is no negative
margin on the buttons.
Change-Id: Id2ebf7aa0b27da1d03d56f59e8a9a96f7656106d
The ResizingDragBar makes the editor resizable, so we need to set the
CodeMirror height to 100%. Previous attempts to fix this at
Ib49d1d9e71 and I4deeda192b suffered from race conditions based on
which modules loaded first. We can avoid this by simply putting the CSS
rule here in WikiEditor.
Bug: T357794
Follow-Up: I4deeda192bdc233101ba61739a636f8fd143c1de
Change-Id: Ia5e9767e0814eac29d58bc0d9c1023344a29dd84
If the form is reset, make sure that the preview is re-run.
There isn't actually any reset button in the normal edit
form, but Edit Recovery uses reset() to remove any
recovered data, and if RTP is open when that's done the preview
needs to be updated.
Bug: T351821
Depends-On: I1ec757d5ddd9f0db66496c6aaef70747d93a5c83
Change-Id: I30481edae4c071e8586ac1dc7d587bd550965967
Steps to reproduce:
* Start making changes to a page in the classic editor.
* Use the normal "Show preview" or "Show diff" button at the bottom
of the editor. The page reloads and now shows a preview/diff at
the top, above the editor.
* Now start using the realtime preview feature on the right side of
the editor.
You will notice that the preview/diff above the editor starts to
flicker, but is never updated. (There is no need to update it. The
realtime preview that is updated is the one in the right pane.)
The original code was added via T293347. I believe the flicker
exists since then. It's effectively a misconfiguration. I hope the
comments make this clear.
This is also a direct follow up to T307046 where the diff view was
fixed (it just disappeared before), but flickers since then.
Bug: T293347
Bug: T307046
Change-Id: I481610389cec902268a8fd09f6b0452131752d54
Replacing 'mediawiki.ui/variables.less' @import with
new skin-aware 'mediawiki.skin.variables.less' standard.
Also
- replacing several static values with new Codex design token featuring
skin variables.
- reinstate static values only on resizeable drag bar. This is not a
standardized component yet and will be revisited with further Codex
component definitions in future.
Bump required MediaWiki core version to v1.41.0.
Bug: T319381
Bug: T332541
Change-Id: I323561894ddf23aa89f51439fc9df2b7642eaca5
Delete almost all code realting to the onboarding popup (blue
pulsating dot) and Beta Feature. Leave only one line to delete
any existing localStorage item that was used to remember the
dismissal of the onboarding popup.
Bug: T327515
Change-Id: I8d05e143858a2269dd6f3302dcc6cee6b0855ffd
The #wikiPreview element can contain other child elements such
as the already-removed one of .previewnote but also (on category
pages) category lists, which we don't want.
This changes to only clone the specific content element. We could
just create this in JS, but don't at this point have access to
the lang direction.
Bug: T315558
Change-Id: Ifcd02e9cf005e00c8dd69df162893fb673117231
Add `position: relative` to .ext-WikiEditor-realtimepreview-preview`
per this suggestion (T315049#8174670) by Matma Rex.
Bug: T315049
Change-Id: I70813f68ffd74fab4978127ecee9bd557d467ebb
Set inManualMode to the result of the current prefers-reduced-motion
setting.
Add another property (reducedMotion) for later UI/message work
Bug: T314787
Change-Id: Ifeb8b996430830499945e73eca2dcfe0355c8046
Because the manual-mode bar gets hidden when an error message
is displayed, it's necessary to re-show it after the preview
is reloaded from the error message. This was done in the
below patch, but that didn't account for all conditions.
Follow-Up: I26150c190a9d3816e35ba369536e6d0ac11e4b1a
Bug: T307240
Change-Id: I0e9698faebd3f4df41221d6ba0b0f5f82ae3ae5b
Add following logging events:
* preview-realtime-error-stopped: triggered when realtime preview
auto-load is stopped.
* preview-realtime-reload-error: triggered when realtime preview pane
shows an error message and the reload button shown in this message is clicked.
* preview-realtime-reload-hover: triggered when the reload button
that shows on hover in the realtime preview pane is clicked.
* preview-realtime-reload-manual: triggered when the reload button in
the realtime preview pane manual bar is clicked.
Bug: T306176
Change-Id: I0785b0a8e88125a9bb30ff5c64c8a7c50b556c63
* Call the parent constructor.
* Add CSS class to the widget's existing $element, rather than
creating a new one. Doesn't really change anything, just looks
neater.
Change-Id: I67a72b5e2ef0912c7c7f7a44c87b31c08e1f7fcb
Move the resize handler from the RealtimePreview constructor to the
getToolbarButton() method, to prevent it being used when the button
is not used (e.g. if the gadget is misconfigured).
Bug: T309330
Change-Id: I7abc335112648605404785528b37a81d946e900e
Save the current caret position in the textarea before enabling
or disabling Realtime Preview, and restore it afterwards.
Bug: T311496
Change-Id: Ib906e96e4e8b94b4e1fd82f6201005394c8a27c5
