In T209939#4842622, @Alex_brollo wrote:

@Zdzislaw How? By javascript? There's a running code anywhere?

@Ineuw: For my money this glitch is entirely related to browser-end caching and not at all related to Gadget or Purge alternatives. (I have no idea why one of my machines occasionally requests the Serbian version of Dynimg.css; a different machine never once seems to.) May I recommend a more conservative encoding within https://en.wikisource.org/wiki/MediaWiki:Common.css, re-expressing:

Some background if I may:

Thanks echoed. (Now please take care in case T146160 repeats this saga.)

@Samwilson: technically Yes, as Change 311769 was incorporated into both 1.28.0-wmf.18 and 1.28.0-wmf.20 via (still open) T145724. Clearly this process has occurred in reality.

@Samwilson: If you are getting concerned over things like this then compare with this which occurred long before your changes.

@Alex_brollo Presumably you are aware that the default height is set (for both horizontal and vertical layouts) in Preference setting [[Special:Preferences#mw-input-wprows]]? Are you suggesting there ought to be two independent configuration values?

Thanks @Tpt for making this change apparently painless (now please tell me if you had to fix up too many of my mistakes!) Seems to be working correctly—as far as I can tell—on each of test2wiki, enws and frws.

@Tpt : Thanks for the review. Regarding your comment:

There is a similar issue raised on the English Wikisource (see: What is this tooltip trying to say? on Scriptorium.)

Tentative assignments to each of MediaWiki-extensions-Poem and Mobile-Content-Service. Please review and correct as appropriate.

To cut right to the chase, ShakespeareFan00 wants to do things with ProofreadPage's <pages> tag (e.g. embedding header-less and/or footer-less table content) which are incompatible with the hard-coded <div> wrappage of embedded content enforced here: (near end of PagesTagParser.render), and wants to open up a discussion on the possibilities of relaxing this requirement.

In T134652#2279018, @Physikerwelt wrote:

I do not understand the connetion to the sqrt example. Try the following in a LaTeX editor

Please do not worry about this. It was a (perhaps misguided) attempt to point out how including or excluding empty elements—here [] rather than {}—ideally should not affect the resultant rendering. Pardon adding to the confusion.

@Physikerwelt I do quite agree on the syntax detail. Unfortunately the prior behaviour (accepting optional closure in {} even though not demanded after a \displaystyle, \scriptstyle, or \textstyle directive) happened to be gracefully handled by the prior codebase, which sets a certain expectation that future developments not change this behaviour.

Thanks for opening T134652—in hindsight that is what I should have done.

@Physikerwelt:
I am guessing here but there likely are only a few legacy usages of \…{}—and those probably result from poor template or editing choices and will be picked up and addressed soon enough on a needs basis.

In T131177#2272049, @Physikerwelt wrote:

In T131177#2271287, @AuFCL wrote:

The simplest test case I have been able to isolate is this:

<math>\textstyle{}</math>

Works under PNG mode, fails reliably under MathML mode. First noted—as far as I am aware—at enWS.

Ok. What are you expecting to happen? Just ignore the command? For me throwing an exception seems the right thing to do.

In T131177#2269837, @Physikerwelt wrote:

There was no negative feedback with regard to the recent changes, so I guess it's time to fade it in in production.

I hope that nobody reading this is so naïve as to expect each 'entry pane' to contain balanced HTML. Assemblages (such as Page:-as-a-whole; or results of <pages/> transclusion ) yes; but normal practice in the wikisources is that individual templates, modules or page sections frequently contain unbalanced HTML which is only resolved at a higher level structure. See for instance hanging indent inherit template usage on enWS alone (around 3600 uses).

This may just be a "lookalike" case but posting in case it may be of use:

@sirens_of_mimas: This would appear to be a manifestation of T122400; I applied the local "temporary fix" described there there and it worked (for an equivalent case for me at least.)

@Billinghurst O.K. Pardon my confusion but how, then is this proposal not a re-statement of (nominally already resolved T129077)? Unless I misunderstand this boils down to whether the wiki "controlling" notifications is the individual user's Home wiki, or (always) Meta?

Isn't this just a special case/suggested implementation of T130655?

"Traditionally" (by which I mean at least for the last couple of years) \mbox{} has not accepted most Unicode content and instead thrown the errors originally detailed.

In T129764#2121228, @Mattflaschen wrote:

In T129764#2118871, @AuFCL wrote:

Thanks @Mattflaschen. All good to know and makes sense now the topic is "hot."

If JavaScript was being blocked entirely, you wouldn't see the error (which is displayed by JS). It seems in this case Privacy Badger was blocking third-party CORS JSON requests. So the error message was actually right.

So just to be clear the text "Error Access to the remote domain was denied." is being emitted by the browser in a non-controllable fashion?

No. This is the text we're using in response to a 'http' error. Now that I look at it, we actually have more detailed error info in this part of the code already (in errorObj). This may help, but browsers are sometimes cagey about revealing the cause of permissions errors.

Thanks @Mattflaschen. All good to know and makes sense now the topic is "hot."

Although in hindsight this error message now makes more sense than initially may I urge that the error text be modified to more suggest that the root cause is the user's browser rather than somewhere between host servers? Even stating that javascript execution is being blocked (if detecting such is even possible—is this a "catch-all" situation?) might considerably help diagnose similar circumstances next time they arise.

In T129764#2115370, @Quiddity wrote:

I believe this is caused by the NoScript browser extension, and you just need to whitelist the domain.

Thanks Andre for the good advice. I removed the comment as subsequent discussion with @GOIII pointed up the fact that technically "solving" this involves a political/expectation aspect I had not considered.

Prior comment removed. Good intentions but further discussion reveals proposed patch answers wrong question.

In T108437#1802458, @Krinkle wrote:

Can this task be closed now?

In T108437#1544095, @TheDJ wrote:

I think it would be good if some authors read the entire documentation page on doing toolbar customization, and especially the part on modifying.
https://www.mediawiki.org/wiki/Extension:WikiEditor/Toolbar_customization#Modifying_things

But I'm still not rly clear on what kind of problems wikisource is experiencing, so I can't be sure that is the right advise..

In T108437#1543038, @Mjbmr wrote:

Calling final WikiEditor modifier with $(document).ready would work.

With regards the comment above at no point to the best of my knowledge was the old ("legacy"?) toolbar affected.

In T96494#1223353, @Nasirkhan wrote:

Added 2 characters and changed the order at https://en.wikisource.org/wiki/User:AuFCL/specialcharacters.json and i think there are no change needed

@Hrishikes, @Nasirkhan: What follows is my best attempt for mashing everything together in what (I hope) is the correct format. I have no way of even validating whether the result is legal JSON so please clean up any errors you spot! prototype specialcharacters.json

In T96494#1223070, @Hrishikes wrote:

See the examples মিস্মি (without zwnj) and মিস্‌মি (with zwnj). If you can visually appreciate the difference, that should be the justification.

In T96494#1223030, @Krenair wrote:

Could you submit a patch against MW core's resources/src/mediawiki.language/specialcharacters.json please?

No fault apparent using Firefox 34.0 (& 35.0 - browser auto-updated during trial; unexpected two-for-one result) under GNU/Linux; both logged-out and in.