We relied on some white space baked into the background-image
to "reserve the space" for the text. If we tried to make the image
smnaller, the text would start overlapping it.
Remove 100px of vertical white space from the image files, adjust
the styles so that text is displayed below the image rather than
overlapping it.
Bug: T191095
Change-Id: I2f19128a2044b3505cdea93c3f587fe62553071d
If the wiki runs on a host that contains a port number, section edit
links would always reload the page, and the "Add section" tab would
not work.
As it happens, my local testing wiki runs on localhost:3080.
It is an unfortunate naming mishap:
* mw.Uri#host is equivalent to location.hostname
* mw.Uri#getHostPort is equivalent to location.host
In this case, we have to compare the port too, otherwise a setup (my
setup ;) ) where one starts up another wiki on localhost:3081 to test
cross-wiki features would fail.
Change-Id: Ib7de4ba3c3a84888f24186af03bd9dcced131051
It contains some rare options that we don't currently make editable,
and we don't set it when creating new image nodes.
We could change our code to always set it, and consider it required,
but that would theoretically be a break in backwards-compatibility.
Bug: T198660
Change-Id: I6e77cce257f733f0f8f6e896b967177ff01658c6
There is something about ActionFieldLayouts with `align: 'left'` (the
default) and no label that causes Firefox to render them differently
than we expect. I am not sure if the bug is in OOUI or Firefox, but it
is easily avoided by just using `align: 'top'` instead (it looks the
same, since there is no label, and it avoids the issue).
Bug: T198274
Change-Id: Ic6077e576b504e7a0cd761c8bac24d4079ae6702
What happens when an edit tab is clicked is spread across handlers in
DesktopArticleTarget and DesktopArticleTarget.init. Consolidating the logic
into the handler in DesktopArticleTarget.init makes it easier to understand.
It could be moved further into DesktopArticleTarget, but the init handler has
to exist to activate the target in the first place.
This patches a hole where clicking "edit source" while in visual mode would
sometimes not switch to source mode, because it didn't think it was changing
the current section.
Also, fix a typo in the documentation.
Bug: T198272
Change-Id: I12d958b6af1b9fa9aca68b498eb2a1a2d76b5a82
New changes:
664b9017b ve.dm.Document: Handle no valid offsets in #getNearestCursorOffset
879e319d4 Don't break before/after multiline insert in source mode
386344d19 LinkContextItem: add label information to the context
Bug: T124305
Bug: T197651
Bug: T198010
Change-Id: Ic0b16b7f85f91ce699eb90f8ee171fc69c9ddd53
New changes:
4418e04c5 Localisation updates from https://translatewiki.net.
12fd1e53e Add isResizable method to dynamically disable resizing
87047170d Use getter to retrieve change stores
58150e710 Use ve.dm.Change object for completeHistory
bc9a1a8af Fix appearance of source surface
Change-Id: I7654d9859741dfbfb0a053a72d0d00b34f1835d6
aeb4f2f2b7 added a #wpTextbox1 to the wikitext surface, which confused our
existing teardown check. This confusion only became apparent in single-tab
mode, when using the wikitext editor.
Bug: T197615
Change-Id: I98e64e7135aaf6f8fda441a91e6cbc4bac6cea39
New changes:
c5df99d3a Remove remaining assert.expect's
593b09992 Localisation updates from https://translatewiki.net.
14a29056c Follow-up 593b099: Add 'lfn' language to build to unbreak the repo
faba29bde Fix cursor position when adjacent to a nail
9854cc88c Sanitize message body in standalone using DOMPurify
52bd0592b ve.dm.Change: Store DOM node arrays as single strings
Local changes:
Add sanitize module
Bug: T197723
Bug: T197894
Change-Id: I572f5bcc80175cc50ef176efb961c9b10b38c7f0
We already do it after save, but not if the editor is closed without
saving.
This behavior is a bit awkward for non-existent pages (redlinks),
since MediaWiki normally doesn't display them in view mode (all links
point to action=edit). But this seems less weird than not allowing the
editor to be closed.
Bug: T122388
Bug: T168338
Change-Id: Id9ee41356f011dfbfa6e8744b8d9076f8eacaf39
