We had some crazy stuff here with negative margins, border boxes and
what not. There were some problems with IE versions, zooming in and out
in pages and with the side by side preview.
This should take care of those. Mostly it moves the borders inside the
elements that are 100%. This was also required because of the
side-by-side preview which was using a dirty trick to hide the border at
the top
Bug: 26828
Change-Id: I3c3466fac53df3e79de6f12f404005e55409fa7c
This makes sure that on narrow page views, it's contents won't bleed
into the textarea.
Bug: 37392
Change-Id: Ia14b354a5a2de049d219e735795a9bd9f558f660
because apparently we do have empty tools boxes. Alternative
implementation in I4652ade66c6de864ee3e74b3817ed9b93967ce3d
This reverts commit dd46fc383b.
Change-Id: I358c34d63261989d49b0a4156cbc05b544727d5c
According to the jQuery documentation (and code) all kinds of
$( '<element>' )
$( '<element/>' )
$( '<element />' )
$( '<element></element>' )
are identical. So yes, this patch does not change anything. All it
does is removing characters that are ignored anyway. Using the same
style everywhere makes the code easier to read and understand and
may save a few bytes when it is gzipped.
The current WikiEditor code contains 67 usages of that jQuery call.
Only very few of them are not in the most simple <element> style.
Personally I consider the style <div/> confusing since a <div> can
not be a void element.
Change-Id: I816b4cccc9ee329e9bcdd9bd2353e5653fd10c36
This line forces sections to be visible after you edit the toolbar.
There is no apparent reason why this should be necessary. It has been
in there almost from the start, but doesn't seem to be used
Change-Id: Iadaae3fb9ae1899e12605d653b2688616b8f7c40
IE11 replaced document.selection by window.getSelection, which breaks
dialogs in WikiEditor, because document.selection.createRange was
accessed without check. Inserting this check unbreaks the dialogs.
Bug: 57489
Change-Id: I70d49fb43bbf7602f43e9a8086ecd32027cb6d6f
eqeqeq:
* Change loose comparisons to strict comparisons where
it seems safe to use a strict comparision instead.
Mostly comparisons to strings or objects, and comparisons to
numbers where the other value is known to be a number, too.
E.g. foo == 'string', bar == node, indexOf() != -1.
* Add eqeqeq:false to files where there are non-obvious usages
left.
onevar, quotmark:
* Disabled in files with lots of style violations.
unused:
* Remove unused variables that have no side-effects in their
assigned expression.
Coding style cleanups on affected lines where trivial.
Change-Id: I5db155a632740e24cb52dba2177c7fc35d5aebd5
* Added closures for jQuery where missing.
* Added closures for mediaWiki where missing.
* Using ready( $ ) where possible.
* Removed empty CSS block.
Change-Id: Ifdd4b10063221a4967d812eafd43858623ec5d28
jslint:
modules/jquery.wikiEditor.toolbar.config.js: line 818, col 43, Extra
comma. (it breaks older versions of IE)
Bug: 52715
Follow-Up: I8c5a52c74fa1bc83c662d748731f96bcd91374d0
Change-Id: I99c16f01176a954ad924a5c493e43fb47206fa4b
Removed redundant attributes, added aria-* attributes and properly
declared the links with role=button.
Tested with JAWS 14 and NVDA.
Bug: 24592
Change-Id: I27e18798d18b63655ea716eee2be1c7ab5303759
Ported from Vector extension's ext.vector.footerCleanup module, but
with less hacks. Depends on change Id9269876 in MediaWiki core.
Also remove unhelpful comments.
Bug: 43689
Change-Id: I36ecd06b6fc0cc5ce95bc43db303b1b542e6c81b
The mix of <div> and <a> tags, being floated left inside a floated left
group seems to cause a flow error in some browsers, which ends up
wrapping the last item in the group. The give-away to what was going on
was that this only happened for groups with labels.
While diagnosing it, I notice that the bug did not occur if the labels
were hidden (suggesting is has something to do with the label being
included in the flow of the group, not the build-out), and converting
them to spans fixed the problem.
Bug: 27698
Change-Id: I2a842a86ef77a8934095c04408b7fabbcfbb2476
ClickTracking is deprecated; the config var gating this behavior is set
to false; the data is going to /dev/null; no one is interested in
analyzing it. I think it's dead, Jim.
Change-Id: I71ea8c174e5e38b28f128ccd380ed2a25ad50606
* This is similar to wikiEditor-toolbar-buildSection-*, but for when
all of the initial sections are done.
* It allows other code to render after this vertical shift is done.
Change-Id: I4705d09b9ef90c1ab8dad93db3f91e70c5fd4d5b
Two fixes:
* The Cancel button previously simply did nothing. However, since it's a
button, it caused the form to be submitted - essentially saving the edit
instead of cancelling it.
Now it sets window's location to "Cancel" link's href (already present in
vanilla MediaWiki) and cancels the submitting of the edit form.
* The Publish button did nothing as well (except that it cancelled the form
submission). This was caused by the dialog it was supposed to show not being
initialized.
I simply forced its initialization using "immediateCreate: true".
Change-Id: I64589985b6075183e66eaa40bc457acbbae380b1
The value is 1000 and this number can only be change in the JavaScript
code. It's unlikely this will be done, and if it's done, the message can
be changed easily.
Change-Id: Iff2553112af52ccb22627301c68db63595ec3cf2
Specifies textarea width of 100% for legacy skin support, and per suggestion by Daniel Friesen, adds a box-sizing specification to prevent the WikiEditor interface from overflowing from the bodyContent.
Change-Id: I8b3369f584c636dfb03685c16f838ea94e6fc0fb
Right now, the Special Characters interface in WikiEditor shows all
characters in a monospace font which makes it especially difficult to
distinguish the different dash characters. The solution implemented
in this change is to add title tooltips to the following characters:
en dash, em dash, minus sign. The title tooltips are localizable and
can be added to any other characters as needed. If we eventually want
to add title tooltips to all the characters, we should come up with a
config shortcut like we're using for Hebrew vowels.
Change-Id: I7eb207acda045a868ec4c625c39bfd3d1f78ea17
This patch sets the "thumb" format as the default format for images added
using wikieditor toolbar, with or without dialogs enabled.
Change-Id: I707b02c63b7253bd29b960a58c0fc10e1d013fb4
This has been a popular request, because people often have to
interrupt their search to make certain changes and then want to
resume.
Change-Id: Id537ffe439d4522add300d8c1355758774dca1c9
The message that currently appears in the box is '(default)' or its
translation. This translation can be a lot longer than it is in English.
This change sets the length according to the length of the actual string.
Change-Id: I9f2151d39e6f3d1cc708ba71e069316c265a8d20
API returns an empty string for invalid and missing properties.
If missing / invalid property are defined, page is correctly flagged.
Change-Id: Id8b28f9ce4fc250853206019e864fe108351add9
Fix for bug 24172, by extending the wikieditor with a file
dialog (like the table and link dialog) for adding files with exended
syntax.
The added syntax is localised. This also fixes bug 24114, and the redirect
button now adds localised magic word.
Change-Id: I5950b530ab8c55aeba4b579cc80ce863f228d373
* Fixed by casting to a String before doing the round-trip check
* While at it, improve user interface to make it harder to make mistakes
and easier to do it "right". By making it an HTML5 "number" input specifically,
and building in min/max settings into the UI.
Old browsers fallback to a plain text input (like it was before).
Most browsers implement this number input by allowing the use of the scroll wheel
and the up/down arrows to adjust the numbers, and not allowing non-numbers or numbers
outside the allowed range.
* Follows-up 7721909f9f
Change-Id: If32da14f80c6a0e4be3e1fe7fd0b650be4ed8a09
* Code clean up in preparation for enabling linting in the future
* Update code to use latest code conventions and best practices:
- Make use of jQuery.Event (e.g. no need to check both e.keyCode
and e.which)
- jQuery: .size() -> .length
- jQuery: (where appropiate) .attr() -> .prop()
Setting properties like 'checked' via attr() has been deprecated
in jQuery.
- Whitespace
- Single quotes instead of double quotes
- Use literal keys in object literals instead of strings
- Pass mediaWiki to closure, use mw. locally instead of "mediaWiki"
global directly.
- Fix indentation
- Brackets around if, else and for bodies
- Strict comparison to 0, null, false, true etc.
- Fix missing radix parameter in parseInt
- Use local $ instead of global $
- Use `foo || bar` instead of `foo ? foo : bar`
- Variable scope hoisting
- Double/redundant variable declarations
- ['foo'] is better written in dot notation
- New line at EOF
- Consistency in jQuery construction:
Tag name for element creation $( '<div>' )
Valid html for html parsing $( '<div foo="bar"></div>' )
- Fix regex escape warnings per JSLint/JSHint.
Do escape ][, don't escape ><
- ..
* Add .jshintrc / .jshintignore
* Updated most files, but not all. Too much at once.
Change-Id: I445639b25a9688b3cdf9e5449e3d31cbcfa9c7ae
The characters are detailed in the bug report.
Patch set 2:
* Amended commit message with bug number.
Patch set 3:
* Added comments to the Cyrillic section for readability.
* Added dotted circle to Palochka to differentiate from I.
* Moved the newly added Ѐ and Ѝ near Е and И.
Change-Id: I2d944926e2769f8691626190259d2466c0e2a8ec
To allow users navigating the text markup buttons by keyboard
the span tags have been replaced by anchor tags. Also a dummy
link target has been added to make sure screen readers recognize
these tags correctly.
Change-Id: I9ec1543f3a39b57452d72067cf85b11e9351f546
Added support Devanagari characters in the WikiEditor. This includes all
characters as per http://unicode.org/charts/PDF/U0900.pdf
Change-Id: Iecab40aaf024c4ee40db142373ee94d90507b9c2
Original support for RTL here was written before ResourceLoader, now
ResourceLoader handles it and this special code for RTL shouldn't exist
:)
Long time ago some css specific for RTL was added for supporting RTL with
body.rtl (before ResourceLoader). However now it is not needed as
ResourceLoader already flips right/left, and moreover it even causes wrong
direconality as ResourceLoader flipps the special handling for RTL.
Changes:
1. dialogs buttons were on right (in English buttons on the
right side too) => now on left side
2. Title of dialogs was in left, and close on right => now title is on
right and close on left
3. Link dialogs: the "Target Page" and the icon for "Broken/Good link" was
flipped
Change-Id: Ia85dfcfcea5945d088cffc4da6198fa506933f81
Instead of wiping the old toolbar out on the server side we now just wrap the old toolbar in a div that has an inline style that prevents it from being displayed. This is only done when the toolbar is enabled. When the toolbar code runs on the client, if the toolbar ends up being incompatible, the old toolbar's wrapping div is shown. This avoids the side-effect of the old toolbar showing up momentarily while the new toolbar loads. It's a dirty hack, but we explored this extensively and it's the least evil way we could come up with that worked consistently.
Change-Id: I6fefadea4dbd01b96a0b95c50bc9ef526144dc3c
This makes jquery.wikiEditor.toolbar.config.js pass jshint (the
command-line jshint from npm that is)
Change-Id: I74d353c956c2b9616a9f80e10d5309ae9ee544db
New characters are added and existing characters are reordered
according to comments received from the Gujarati Language support
team.
Change-Id: I769594ec1088d2c3326477a3f1065d576c6dcdf7
The diacritic is supposed to appear after the dotted circle. It is
already like this in other languages.
Change-Id: Id157ab58ae41bd6e8f78c26b35b65003abc7bf7a
Will now check if character is defined and will return empty string as result instead.
Added a mw.log to catch this situation for developers.
Based on patch by User:Lupo.
Bug 31673
Submitter's comment: "Replace next" now replaces the currently selected text instead of finding the next occurrence and replacing it. To keep the location of the current occurrence, i added matchIndex to $(this).data.
I added some comments renamed a couple of variable for readability:
* s to textRemainder
* replace to actualReplacement
This is my first significant jQuery-style patch so it may have embarrassing mistakes - constructive criticism is welcome.
Split the Arabic section in jquery.wikiEditor.toolbar.config.js into Arabic and Arabic extended. Arabic contains the core 28-letter alphabet, special letters for the Arabic language, vowels, punctuation and digits. "Arabic extended" contains most of the other letters and signs that are used by languages such as Arabic, Urdu, Balochi, etc.
- Leaked globals
- Strict comparison to 0, false and ''
- Missing semicolon
- Variable name collision
- Minor improvements in caching (in a few places "var $that" cached $(this), but wasn't actually used)
- Replace calls to deprecated $j with $
- Checking undefined by strictly comparing references instead of a string comparison and typeof (speed)
(see bug 29106)
* Reintroduce support for the splitlines argument in encapsulateSelection(). Was implemented by Adam Miller in r61493 but got lost somehow
* Add 'splitlines': true for the bullet list and numbered list buttons. The indent button already had it, so that part of r61493 did survive
* Copy options.pre and options.post to local pre and post variables instead of using (and modifying!) them directly all over the place
Some langages (Croatian, Hungarian, Polish, Romanian, Serbian)
use DOUBLE LOW-9 QUOTATION MARK (U+201E) and
RIGHT DOUBLE QUOTATION MARK (U+201D) in marking up
quotes. For more details, see:
http://en.wikipedia.org/wiki/Quotation_mark,_non-English_usage
What actually happens here
* Add $localBasePath, $remoteBasePath params to the FileModule constructor, defaulting to $IP and $wgScriptPath respectively
* Add getLocalPath() and getRemotePath(), which use this information to build a proper FS or URL path for a file
* Make readScriptFiles() non-static so it can use these functions
* Run every single file path we use through either getLocalPath() or getRemotePath() as appropriate
** Except file dependencies, these are already prefixed. Our inability to give them special treatment caused bugs earlier
* Kill prefixFilePathList() and resolveFilePath(), no longer needed
* Abstracted the requirements concept being used to hack in the iframe as a context extension requirement
* Removed some hardcoding for iframe stuff
* Moved about 60k of JavaScript code out of the main wikiEditor script, and into an iframe only context extension.
