When the ListToolGroup in the toolbar (the "More" section) is scrolled
down such that the top tool is partly obscured, and you hover over the
bottom half of the "More" button, the top tool displays a hover effect
and using the scroll wheel will scroll the list rather than the page.
This is because the list has a box-shadow that's 1em tall, and the
height of the "More" button is 2em. And in Chrome, pointer events
"work" even in the box-shadow area. Roan reported the Chrome bug at
https://code.google.com/p/chromium/issues/detail?id=314291
This change works around the bug by making the tools in the list
inline-block instead of block; for some reason the bug only affects
block elements.
Change-Id: I4ea3f41c91d0ff5d5cc150fe8acc3427f0ab5f3a
Some 've-ui-toolbar-bar' classes hadn't been converted to OO.ui so the
toolbar had no border. Also removed a useless rule in mw.ViewPageTarget.css.
SA platform didn't override OO.ui.msg to use the ve.msg so no messages
were getting through.
Change-Id: Ieb5bc3c98d1c435ec194b201b517a688cd9b02b9
* Our metadata insertions now need to be the same length as the data
insertion, not one more, so:
** Remove the +1 in the listMetadata splice
** Shorten the metadata variable by dropping the merging of the
metadata right before and right after the internal list; it was
also including the metadata right after the internal list twice
*** We still need to deal with this in some way though, left a TODO
** Fix the metadata insertion test for these changes
* Fix null reference keys in the test data; we made all references
keyed a while ago, but this test data was never updated for that
** The remapping of reference data doesn't remap auto/N keys yet,
left a FIXME for that
Change-Id: I8ef4e6ee7c1808574d81d0b83294848afd400cd7
Stop using this.$.frame.dir - a horrible hack made of duct tape
and bubble gum.
Or perhaps rather, masking tape and post-it-notes...
Change-Id: I53690e4485974b95edbdd255c0b96c2f639c5261
Objectives:
* Rename this.$ to this.$element
* Rename this.$$ to this.$
* Get rid of the need to use this.frame.$$
* Rename OO.ui.Element.get$$ to OO.ui.Element.getJQuery
Changes: (using Sublime Text regex patterns)
* Replace "get$$" with "getJQuery"
* Replace "\.(\$)([^\$a-zA-Z])" with ".$element$2"
* Replace "\.(\$\$)" with ".$"
* Replace "'$$'" with "'$'"
* Set this.$ to null in constructor of OO.ui.Window
* Set this.$ to this.frame.$ in initialize method of OO.ui.Window
* Replace "\.(frame.\$)([^\$a-zA-Z])" with ".\$$2"
Bonus:
* Use this.$() in a bunch of places where $() was erroneously used
Change-Id: If3d870124ab8d10f8223532cda95c2b2b075db94
If configured to do so, the VE API will forward the Cookie: header to
Parsoid. This allows VisualEditor to be used on read-restricted wikis.
Bug: 44483
Change-Id: If4a0cf1e5785b332ec9b014b783412805cf8af75
Replaced uses of extendObject with $.extend . Replaced the one use of
OO.ui.indexOf with Array.prototype.indexOf because that's what
everything else was already using.
Change-Id: I63f40989057b8065ec977efafbf68d6e22c8e679
By serialising the current DOM, and injecting it into a form we can
end up in the source editor with our VE changes converted.
Bug: 50687
Change-Id: Iafcc02a737d9c6c3a59dce1caff130d47ca25650
Calculate and store the two inner whitespace values of the body in the
dm.Document. When converting back, make sure the first/last nodes
pre/post outer whitespace matches the inner left/right whitespace
of the body.
Bug: 54964
Change-Id: I45f1ffd63669f25a6cae878400bfe21719ed58ee
Also removed comment in ui.MWTransclusionDialog that was
copied from dm.MWTemplateSpecModel.
Bug: 50888
Change-Id: I9dcfef3ae65fe716bae91f703f9169171448797a
* Method is private.
* Code example and bullet list were rendered badly due to a
single line break having no meaning in markdown (this makes
80-char linebreaks easier). Need an empty line to separate block
elements (e.g. paragraph from list, and list from next paragraph).
* Fixed #register reference to be a doc link instead. The invocation
parenthesis look confusing (imply it needs no arguments).
Change-Id: Ib6cab4599ec3e310ec4355bdb1d60b1e53429c69
Everyone loves a ligature, but within our codebase we should
be consistent, and sadly that means using en-US, not en-GB-archaic.
Also having non-basic latin characters in filenames is a bit
of a pain for developers.
Similarly for the i18n message, the ligature should go in
MessagesEn_gb if anywhere.
Also in this commit, re-saved the BF thumbnails as plain SVG.
Change-Id: I21a2bf040bed132d3f1c73c916c731d36e0ad852
