Page MenuHomePhabricator

Fomafix (Fomafix)
User

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

User Since
Oct 14 2014, 8:51 AM (245 w, 11 h)
Availability
Available
LDAP User
Unknown
MediaWiki User
Fomafix [ Global Accounts ]

Recent Activity

Yesterday

Fomafix claimed T225845: Remove support for automatic 'dir' parameter inference for load.php urls .
Mon, Jun 24, 12:05 PM · Patch-For-Review, Performance-Team (Radar), patch-welcome, MediaWiki-ResourceLoader

Tue, Jun 18

Fomafix added a comment to T68598: mw.loader state of module stuck at "loading" if request was aborted.

Maybe the online and offline events are also interesting in this context.

Tue, Jun 18, 3:51 PM · Performance-Team, JavaScript, MediaWiki-ResourceLoader
Fomafix added a comment to T225992: Get language fallback chain from URL parameter instead of from Language::getFallbacksFor.

This change is similar to T225845: Remove support for automatic 'dir' parameter inference for load.php urls .

Tue, Jun 18, 10:56 AM · Performance-Team, MediaWiki-ResourceLoader
Fomafix added a subtask for T225992: Get language fallback chain from URL parameter instead of from Language::getFallbacksFor: T225899: Set the default parameter for load.php in client-side by a parameter in server-side.
Tue, Jun 18, 10:55 AM · Performance-Team, MediaWiki-ResourceLoader
Fomafix added a parent task for T225899: Set the default parameter for load.php in client-side by a parameter in server-side: T225992: Get language fallback chain from URL parameter instead of from Language::getFallbacksFor.
Tue, Jun 18, 10:55 AM · Patch-For-Review, Performance-Team (Radar), MediaWiki-ResourceLoader
Fomafix created T225992: Get language fallback chain from URL parameter instead of from Language::getFallbacksFor.
Tue, Jun 18, 7:55 AM · Performance-Team, MediaWiki-ResourceLoader

Sun, Jun 16

Fomafix added a comment to T225845: Remove support for automatic 'dir' parameter inference for load.php urls .

I like this one most. It would be very efficient and reduces the amount of information and code required on the client. You can use the existing $VARS that StartupModule and mediawiki.js make use of to very efficiently export these for the current context. I think you can replace reqBase with a $VARS.something assignment to make this work. E.g. skin/lang always, and debug/dir only as needed.

Sun, Jun 16, 8:37 PM · Patch-For-Review, Performance-Team (Radar), patch-welcome, MediaWiki-ResourceLoader
Fomafix created T225899: Set the default parameter for load.php in client-side by a parameter in server-side.
Sun, Jun 16, 7:58 PM · Patch-For-Review, Performance-Team (Radar), MediaWiki-ResourceLoader
Fomafix added a comment to T225845: Remove support for automatic 'dir' parameter inference for load.php urls .

A similar dependency is the call of Language::getFallbacksFor. This can avoided in ResourceLoader by transmitting always the whole fallback language chain instead of only the user interface language. By the way this allows an user individual fallback chain.

Sun, Jun 16, 6:27 PM · Patch-For-Review, Performance-Team (Radar), patch-welcome, MediaWiki-ResourceLoader

Sat, Jun 15

Fomafix added a comment to T225845: Remove support for automatic 'dir' parameter inference for load.php urls .

T181684: Add ability to get language directionality from mw.language also requires the language directionality of a language in JavaScript.

Sat, Jun 15, 8:23 AM · Patch-For-Review, Performance-Team (Radar), patch-welcome, MediaWiki-ResourceLoader
Fomafix added a comment to T225845: Remove support for automatic 'dir' parameter inference for load.php urls .

The server-side part is easy.
The client-side part requires the information of the direction on JavaScript side. I see three possibilities to get this information:

  • Add an addition JavaScript config variable wgUserDirection or wgUserLanguageDirection.
  • Get the information from the existing JavaScript config variable wgUserLanguage via a mapping table. ULS already contains such a table. A complete table is big. Maybe the table can just filled with the used language codes wgUserLanguage and maybe other languages that are used.
  • Get the information from the browser.
  • Add a new
Sat, Jun 15, 8:04 AM · Patch-For-Review, Performance-Team (Radar), patch-welcome, MediaWiki-ResourceLoader

Wed, Jun 12

Restricted Application added a project to T225589: Load search suggestion for strings typed before initializing JavaScript: Discovery-Search.
Wed, Jun 12, 7:37 AM · Discovery-Search, OOUI, MediaWiki-Search
Fomafix added a comment to T224952: On some special pages the search suggestions get shown on browser history back.

I updated the description to match the change. Only the search suggestion field on browser history back is a regression.

Wed, Jun 12, 6:00 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Browser-Support-Firefox, OOUI, MediaWiki-Special-pages, MediaWiki-Search, Discovery-Search
Fomafix updated the task description for T224952: On some special pages the search suggestions get shown on browser history back.
Wed, Jun 12, 5:56 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Browser-Support-Firefox, OOUI, MediaWiki-Special-pages, MediaWiki-Search, Discovery-Search

Tue, Jun 11

Fomafix closed T220489: Use `data-mw="interface"` instead of `mw-data="interface"` as Resolved.
Tue, Jun 11, 8:07 PM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Maps (Kartographer)
Fomafix added a comment to T224952: On some special pages the search suggestions get shown on browser history back.

@Formatierer: With https://gerrit.wikimedia.org/r/514422 the search suggestion gets only loaded when the input field is focused. This should still hit the case when there are type characters in the input field but avoid the case when the value of the input field is restored by browser history back because then the input field is normally not focused.

Tue, Jun 11, 9:50 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Browser-Support-Firefox, OOUI, MediaWiki-Special-pages, MediaWiki-Search, Discovery-Search
Fomafix removed a project from T47668: Position of Search result is wrong hardcoded: Patch-For-Review.

Please verify if rMW578c8e6855ca solves the problem in skin Cavendish. As far as I see is skin Cavendish not compatible with the current version of MediaWiki.

Tue, Jun 11, 7:17 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), MediaWiki-Search, Discovery-Search, MediaWiki-Interface

Mon, Jun 10

Fomafix changed the subtype of T68599: Browser window gets black without exit button when the browser is offline from "Task" to "Bug Report".

I still can reproduce the bug as described in the description.

Mon, Jun 10, 9:51 AM · Multimedia, MediaViewer
Fomafix added a comment to T71893: MMV: Page is completely blacked out when accessing an invalid file name.

At the moment the URL https://en.wikipedia.org/wiki/Mike_Godwin#mediaviewer/File:T<ess.pdf shows a back screen for a short moment and then shows the article again. In the JavaScript console there is the error message

Error: "Unable to parse title"

I guess the behavior is changed compared to original behavior of this task because now the exception is caught and the black screen is removed.

Mon, Jun 10, 9:09 AM · Multimedia, MediaViewer

Thu, Jun 6

Fomafix claimed T47668: Position of Search result is wrong hardcoded.

Skin Cavendish uses a margin on the body element https://github.com/DaSchTour/Cavendish/blob/master/resources/cavendish.css#L84

body {
	margin-left: 5%;
	margin-right: 5%;
}

Therefor https://gerrit.wikimedia.org/r/514564 should solve the problem.

Thu, Jun 6, 9:04 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), MediaWiki-Search, Discovery-Search, MediaWiki-Interface
Fomafix added a comment to T47668: Position of Search result is wrong hardcoded.

Solves https://gerrit.wikimedia.org/r/514564 the problem?

Thu, Jun 6, 8:32 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), MediaWiki-Search, Discovery-Search, MediaWiki-Interface
Fomafix merged T225174: Add anchor links for each section header into T18691: RFC: Section headings should have a clickable anchor.
Thu, Jun 6, 7:42 AM · Patch-For-Review, Readers-Web-Backlog (Design), TechCom-RFC, Design, MediaWiki-Interface
Fomafix merged task T225174: Add anchor links for each section header into T18691: RFC: Section headings should have a clickable anchor.
Thu, Jun 6, 7:41 AM

Wed, Jun 5

Fomafix claimed T224952: On some special pages the search suggestions get shown on browser history back.
Wed, Jun 5, 6:07 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Browser-Support-Firefox, OOUI, MediaWiki-Special-pages, MediaWiki-Search, Discovery-Search
Fomafix added a project to T224952: On some special pages the search suggestions get shown on browser history back: Browser-Support-Firefox.

This part in OOUI causes the restore of the value in the OOUI search input field on Special:Search: https://gerrit.wikimedia.org/g/oojs/ui/+/98dc3e15db7b699f14a1a6277da0d20c0edc554f/src/widgets/TextInputWidget.js#110

		this.$input.attr( 'autocomplete', 'off' );
		// Turning off autocompletion also disables "form caching" when the user navigates to a
		// different page and then clicks "Back". Re-enable it when leaving.
		// Borrowed from jQuery UI.
		$( window ).on( {
			beforeunload: function () {
				this.$input.removeAttr( 'autocomplete' );
			}.bind( this ),
			pageshow: function () {
				// Browsers don't seem to actually fire this event on "Back", they instead just
				// reload the whole page... it shouldn't hurt, though.
				this.$input.attr( 'autocomplete', 'off' );
			}.bind( this )
		} );
Wed, Jun 5, 4:32 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Browser-Support-Firefox, OOUI, MediaWiki-Special-pages, MediaWiki-Search, Discovery-Search

Tue, Jun 4

Fomafix renamed T224952: On some special pages the search suggestions get shown on browser history back from On some special pages the search suggestions get shown on browser histrory back to On some special pages the search suggestions get shown on browser history back.
Tue, Jun 4, 8:57 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Browser-Support-Firefox, OOUI, MediaWiki-Special-pages, MediaWiki-Search, Discovery-Search
Fomafix added a comment to T224952: On some special pages the search suggestions get shown on browser history back.

Hmm, I see. Before rMW72f61f7a5930 on browser history back there was never a search suggestion window but only on some special pages the search input field gets restored on other special pages not. Now when the search input field gets restored the search suggestion field gets showed.

Tue, Jun 4, 6:42 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Browser-Support-Firefox, OOUI, MediaWiki-Special-pages, MediaWiki-Search, Discovery-Search
Fomafix added a comment to T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load.

I created T224952 for the problem described in T224524#5228179.

Tue, Jun 4, 4:46 AM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), MediaWiki-Search, Discovery-Search, MediaWiki-Special-pages, Regression
Restricted Application added a project to T224952: On some special pages the search suggestions get shown on browser history back: Discovery-Search.
Tue, Jun 4, 4:44 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Browser-Support-Firefox, OOUI, MediaWiki-Special-pages, MediaWiki-Search, Discovery-Search

Mon, Jun 3

Fomafix added a comment to T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load.

The problem T224524#5228179 happens on all special pages using OOUI. This issue should tracked on a separate task.

Mon, Jun 3, 6:36 PM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), MediaWiki-Search, Discovery-Search, MediaWiki-Special-pages, Regression
Fomafix added a comment to T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load.

The problem T224524#5228179 gets triggered by

OO.ui.infuse( $( '#searchText' ) )

I don't know what happens here.

Mon, Jun 3, 8:11 AM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), MediaWiki-Search, Discovery-Search, MediaWiki-Special-pages, Regression
Fomafix added a comment to T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load.

On https://de.wiktionary.org/wiki/Spezial:Suche the focus behavior is caused by the JavaScript in https://de.wiktionary.org/wiki/MediaWiki:Common.js.

Mon, Jun 3, 6:04 AM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), MediaWiki-Search, Discovery-Search, MediaWiki-Special-pages, Regression

Sun, Jun 2

Fomafix added a comment to T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load.

I can confirm the problem and it happens since rMW72f61f7a5930: jquery.suggestions: Trigger keypress on initializing and rMWfd5733830383: jquery.suggestions: Do not show suggestions on prefilled values. But it happens only on the general search field on Special:Search, not with the same general search field on other pages and not on other input fields with suggestions. This is strange.

Sun, Jun 2, 7:10 PM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), MediaWiki-Search, Discovery-Search, MediaWiki-Special-pages, Regression

Thu, May 30

Fomafix closed T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load as Resolved.

Verified with https://www.mediawiki.org/wiki/Special:Contributions/Iniquity

Thu, May 30, 1:28 PM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), MediaWiki-Search, Discovery-Search, MediaWiki-Special-pages, Regression
Fomafix closed T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load, a subtask of T220732: 1.34.0-wmf.7 deployment blockers, as Resolved.
Thu, May 30, 1:28 PM · User-zeljkofilipin, Release-Engineering-Team (Kanban), Release, Train Deployments

Wed, May 29

Amorymeltzer awarded T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load a Piece of Eight token.
Wed, May 29, 10:22 PM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), MediaWiki-Search, Discovery-Search, MediaWiki-Special-pages, Regression
Fomafix created T224631: Show only one user exist error message on Special:CreateAccount.
Wed, May 29, 9:49 PM · MediaWiki-User-login-and-signup
Fomafix claimed T224524: Various pages (Special:Contributions, Special:WhatLinksHere) shows autocomplete / search suggestions dropdown on page load.
Wed, May 29, 8:31 AM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), MediaWiki-Search, Discovery-Search, MediaWiki-Special-pages, Regression

May 24 2019

Fomafix closed T223422: Load search suggestion for strings typed before initializing JavaScript as Resolved.
May 24 2019, 6:33 AM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), Discovery-Search (Current work), MediaWiki-Search

May 16 2019

Fomafix created T223422: Load search suggestion for strings typed before initializing JavaScript.
May 16 2019, 7:57 AM · MW-1.34-notes (1.34.0-wmf.7; 2019-05-28), Discovery-Search (Current work), MediaWiki-Search

May 15 2019

Fomafix merged T214863: ULS causes JQMIGRATE: jQuery.fn.offset() requires a valid DOM element into T175236: [ULS] jQuery.fn.offset() requires a valid DOM element.
May 15 2019, 8:00 AM · Patch-For-Review, UniversalLanguageSelector, Technical-Debt
Fomafix merged task T214863: ULS causes JQMIGRATE: jQuery.fn.offset() requires a valid DOM element into T175236: [ULS] jQuery.fn.offset() requires a valid DOM element.
May 15 2019, 8:00 AM · UniversalLanguageSelector
Fomafix created T223352: Catch exceptions from mw.hook handlers.
May 15 2019, 5:08 AM · Performance-Team (Radar), patch-welcome, MediaWiki-ResourceLoader, JavaScript

May 11 2019

Fomafix updated the task description for T214863: ULS causes JQMIGRATE: jQuery.fn.offset() requires a valid DOM element.
May 11 2019, 10:48 AM · UniversalLanguageSelector

May 8 2019

Fomafix claimed T175977: Prevent web crawler from indexing buttons in content.
May 8 2019, 6:08 AM · Patch-For-Review, MediaWiki-General-or-Unknown

May 2 2019

Fomafix updated the task description for T222329: Special:Search generates "TypeError: this.pushPending is not a function".
May 2 2019, 5:10 AM · MW-1.34-notes (1.34.0-wmf.4; 2019-05-07), Discovery-Search, MediaWiki-Search, Regression, OOUI
Fomafix created T222329: Special:Search generates "TypeError: this.pushPending is not a function".
May 2 2019, 5:07 AM · MW-1.34-notes (1.34.0-wmf.4; 2019-05-07), Discovery-Search, MediaWiki-Search, Regression, OOUI

Apr 29 2019

Fomafix committed rETMC650de06c291c: Hook 'SkinEditSectionLinks' does now the HTML escaping (authored by Fomafix).
Hook 'SkinEditSectionLinks' does now the HTML escaping
Apr 29 2019, 9:48 AM

Apr 25 2019

Fomafix added a comment to T174133: Do not catch Ctrl key combinations on focused language selector on Special:PageLanguage.

Yes, the problem was fixed in Firefox 65 by changing the default for dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content from false to true. When I set the config parameter in Firefox to false then the problem is present again.

Apr 25 2019, 4:10 AM · Browser-Support-Firefox, OOUI, MediaWiki-Special-pages

Apr 24 2019

Fomafix closed T174133: Do not catch Ctrl key combinations on focused language selector on Special:PageLanguage as Resolved.

The problem does not exist anymore. Is seams to be fixed.

Apr 24 2019, 8:31 PM · Browser-Support-Firefox, OOUI, MediaWiki-Special-pages

Apr 22 2019

Fomafix added a comment to T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js.

I can not find any JavaScript errors while loading of https://de.wikivoyage.org/wiki/Arnsberg anymore.

Apr 22 2019, 9:43 AM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree

Apr 20 2019

Fomafix triaged T221439: Static mapframe not clickable in 1.34.0-wmf.1 as Unbreak Now! priority.
Apr 20 2019, 8:36 AM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), Reading-Infrastructure-Team-Backlog (Kanban), Regression, Patch-For-Review, Maps (Kartographer)

Apr 19 2019

Fomafix created T221443: JavaScript click hander for watch/unwatch pages on the watchlist is not attached for items loaded from rcfilters.
Apr 19 2019, 10:14 AM · Growth-Team, MediaWiki-Watchlist
Fomafix claimed T221439: Static mapframe not clickable in 1.34.0-wmf.1 .
Apr 19 2019, 9:04 AM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), Reading-Infrastructure-Team-Backlog (Kanban), Regression, Patch-For-Review, Maps (Kartographer)

Apr 18 2019

Fomafix added a comment to T63115: Drop URL parameter setlang.

T25227 requires a token for logout.

Apr 18 2019, 5:07 PM · Performance-Team (Radar), Technical-Debt, UniversalLanguageSelector

Apr 17 2019

Restricted Application added a project to T146349: The logout button and the mobile view button contains the markasread parameter: Growth-Team.

The problem still exist. https://www.wikidata.org/wiki/Special:Notifications contains links like https://www.wikidata.org/wiki/Q3938?markasread=123456789&markasreadwiki=wikidatawiki

Apr 17 2019, 7:01 PM · Growth-Team, Collaboration-Team-Triage, Notifications

Apr 9 2019

Fomafix claimed T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js.

https://gerrit.wikimedia.org/r/502396 is merged. Please test again when it is deployed.

Apr 9 2019, 8:13 PM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree
Fomafix added a comment to T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js.

I found the reason for the race condition:

Apr 9 2019, 5:22 PM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree
Fomafix added a comment to T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js.

Fixed in https://de.wikivoyage.org/w/index.php?title=MediaWiki:ListingEditor.js&diff=1195136&oldid=1195058

Apr 9 2019, 2:14 PM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree
Fomafix added a comment to T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js.

In https://de.wikivoyage.org/wiki/MediaWiki:ListingEditor.js a dependency on module mediawiki.api is missing because it uses mw.Api(). I identified this with a throttled network connection in Firefox.

Apr 9 2019, 1:30 PM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree
Fomafix created T220489: Use `data-mw="interface"` instead of `mw-data="interface"`.
Apr 9 2019, 10:46 AM · MW-1.34-notes (1.34.0-wmf.10; 2019-06-18), Maps (Kartographer)
Fomafix added a comment to T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js.

With https://gerrit.wikimedia.org/r/502396 I fix an failure in Maps (Kartographer) which causes the exception in T220308#5091821.

Apr 9 2019, 10:32 AM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree
Fomafix closed T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js as Invalid.

I just got also the error message above. This error come from extension Maps (Kartographer). As visible result the TocTree gets not executed. But this is not a fault of TocTree.

Apr 9 2019, 5:07 AM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree
Fomafix added a comment to T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js.

There are some missing dependencies in https://de.wikivoyage.org/ that lead to race conditions. But the extension TocTree is not the root cause.

Apr 9 2019, 4:57 AM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree

Apr 8 2019

Fomafix added a comment to T220308: Use $() instead of mw.hook( 'wikipage.content' ).add() in ext.toctree.js.

TocTree is correct as far as I see. Maybe there is a race-condition somewhere else.

Apr 8 2019, 7:15 PM · MW-1.34-notes (1.34.0-wmf.1; 2019-04-16), MediaWiki-extensions-TocTree

Apr 4 2019

Fomafix added a comment to T57876: Add Hakka (hak) to LanguageConverter.

I just rebased https://gerrit.wikimedia.org/r/116691 and applied the changes from similar files.

Apr 4 2019, 7:23 AM · Patch-For-Review, I18n, MediaWiki-Language-converter
Fomafix removed a project from T35871: Port mediawiki.legacy.protect to modern JavaScript: Patch-For-Review.
Apr 4 2019, 7:02 AM · MW-1.33-notes (1.33.0-wmf.25; 2019-04-09), MediaWiki-Page-protection, Technical-Debt, JavaScript
Fomafix closed T215737: The included enhanced RecentChanges has a different collapsible toggle button as Resolved.
Apr 4 2019, 5:56 AM · MW-1.33-notes (1.33.0-wmf.25; 2019-04-09), Growth-Team, MediaWiki-Recent-changes

Apr 3 2019

Fomafix closed T35871: Port mediawiki.legacy.protect to modern JavaScript as Resolved.
Apr 3 2019, 8:26 PM · MW-1.33-notes (1.33.0-wmf.25; 2019-04-09), MediaWiki-Page-protection, Technical-Debt, JavaScript
Fomafix changed the subtype of T207981: uselang=/ leads to unhandled exception in installer from "Task" to "Bug Report".
Apr 3 2019, 5:16 AM · Patch-For-Review, MediaWiki-Installer

Apr 2 2019

Fomafix placed T35871: Port mediawiki.legacy.protect to modern JavaScript up for grabs.
Apr 2 2019, 8:22 AM · MW-1.33-notes (1.33.0-wmf.25; 2019-04-09), MediaWiki-Page-protection, Technical-Debt, JavaScript
Fomafix reopened T35871: Port mediawiki.legacy.protect to modern JavaScript as "Open".

Reopen: The JavaScript global variable window.ProtectionForm still gets assigned.

Apr 2 2019, 8:22 AM · MW-1.33-notes (1.33.0-wmf.25; 2019-04-09), MediaWiki-Page-protection, Technical-Debt, JavaScript

Mar 31 2019

Fomafix added a comment to T36514: Language and direction of first heading should depend on page content language instead of user interface language.

The browser and especially the operating systems have a bad support for the Explicit Directional Isolate Formatting Characters (LRI, RLI, FSI, PDI) introduced in Unicode 6.3:

Mar 31 2019, 12:50 PM · Patch-For-Review, RTL, I18n, MediaWiki-Internationalization

Mar 30 2019

Fomafix closed T219359: lang attribute of page title is empty as Resolved.

@PerfektesChaos I support you comments, but this task is the wrong place. This task is just for restoring the previous behavior after making a typo in the refactoring. This is solved and therefor this task is solved.

Mar 30 2019, 4:10 PM · MW-1.33-notes (1.33.0-wmf.23; 2019-03-26), Regression, User-Michael, Vector, Wikidata-Campsite, Accessibility, Wikidata

Mar 27 2019

Fomafix added a comment to T219340: Remove wgMonthNames and wgMonthNamesShort from mw.config.

There are some gadgets and user scripts that depend on wgMonthNames.

Mar 27 2019, 2:59 PM · Readers-Web-Backlog, patch-welcome, Performance-Team, MediaWiki-Interface, Technical-Debt (Deprecation)

Mar 25 2019

Fomafix created T219189: The DateInputWidget does not close the date selector after a tab.
Mar 25 2019, 5:19 PM · MW-1.33-notes (1.33.0-wmf.24; 2019-04-02), MediaWiki-Special-pages

Mar 21 2019

Mill <mill@mail.com> committed rESCC5d021c959d41: 6baaaaaaaaaaaa (authored by Fomafix).
6baaaaaaaaaaaa
Mar 21 2019, 12:30 AM
Fomafix committed rESCC14fd48890b44: Integrate module 'ext.TwoColConflict.Inline.BaseVersionSelectorCss' (authored by Fomafix).
Integrate module 'ext.TwoColConflict.Inline.BaseVersionSelectorCss'
Mar 21 2019, 12:29 AM

Mar 14 2019

Fomafix changed the subtype of T213767: HTMLSelectField doesn't use the `default` value when an invalid value is submitted from "Task" to "Bug Report".
Mar 14 2019, 8:35 PM · MediaWiki-HTMLForm

Mar 8 2019

Fomafix added a comment to T213767: HTMLSelectField doesn't use the `default` value when an invalid value is submitted.

On Special:AllMessages the parameter limit has the same problem. The drop down menu has values for 20, 50, 100, 250, 500 and 5000. The default is 50. When using a different value in the URL parameter limit like limit=2 the query on the system messages get correctly limited to 2 entries. In case of a value which is not in the list of the drop down menu the preselected value is always 20 because 20 is the first entry in the list. Expected value is 50 because this is the default value when the parameter limit is not present.

Mar 8 2019, 10:23 AM · MediaWiki-HTMLForm

Mar 4 2019

Fomafix added a comment to T89561: Implement a CSS preprocessor for direction flipping based on the content direction.

The selector .mw-editsection is a bad example because it is (mostly) used in content. I currently can not find a usage on a special page. But I'm sure there is one.

Mar 4 2019, 6:48 AM · Performance-Team (Radar), MediaWiki-ResourceLoader

Mar 3 2019

Fomafix added a comment to T89561: Implement a CSS preprocessor for direction flipping based on the content direction.

It is intended to have .mw-editsection in the user interface part and in the content part.

Mar 3 2019, 9:32 PM · Performance-Team (Radar), MediaWiki-ResourceLoader
Fomafix updated the task description for T89561: Implement a CSS preprocessor for direction flipping based on the content direction.
Mar 3 2019, 9:31 PM · Performance-Team (Radar), MediaWiki-ResourceLoader

Mar 2 2019

Fomafix changed the subtype of T105214: Preview shows wikitext instead of page title on test.wikipedia.org from "Task" to "Bug Report".
Mar 2 2019, 2:15 PM · JavaScript, MediaWiki-Page-editing
Fomafix changed the subtype of T151524: Maps fast preview is broken on 2nd attempt from "Task" to "Bug Report".
Mar 2 2019, 2:14 PM · Maps (Kartographer)
Fomafix added a comment to T105214: Preview shows wikitext instead of page title on test.wikipedia.org.

https://test.wikipedia.org/wiki/MediaWiki:Editing got deleted so it is no longer reproducible on this project.

Mar 2 2019, 2:10 PM · JavaScript, MediaWiki-Page-editing
Fomafix changed the subtype of T180342: Single quotes in selflinks activates italic/bold from "Task" to "Bug Report".
Mar 2 2019, 11:54 AM · MediaWiki-Parser
Fomafix changed the subtype of T185904: Special:Upload fails on ":w:" as destination filename from "Task" to "Bug Report".
Mar 2 2019, 11:52 AM · Multimedia, MediaWiki-Uploading, MediaWiki-API
Fomafix changed the subtype of T208145: api.php?uselang=sr shows language converter syntax in the HTML from "Task" to "Bug Report".
Mar 2 2019, 11:04 AM · MediaWiki-API, Patch-For-Review, MediaWiki-Language-converter, MediaWiki-Parser
Fomafix updated the task description for T212276: Suggestions of input field on Special:Categories strips leading "Category:" from category name.
Mar 2 2019, 10:26 AM · MediaWiki-Special-pages
Fomafix changed the subtype of T212276: Suggestions of input field on Special:Categories strips leading "Category:" from category name from "Task" to "Bug Report".
Mar 2 2019, 10:21 AM · MediaWiki-Special-pages

Feb 28 2019

Fomafix changed the subtype of T213479: On Special:AllMessages the URL parameter lang with empty, invalid or unknown value selects language 'aa' from "Task" to "Bug Report".
Feb 28 2019, 7:58 AM · Patch-For-Review, Regression, MediaWiki-Special-pages
Fomafix changed the subtype of T214863: ULS causes JQMIGRATE: jQuery.fn.offset() requires a valid DOM element from "Task" to "Bug Report".
Feb 28 2019, 7:57 AM · UniversalLanguageSelector
Fomafix changed the subtype of T187866: The language code 'no' is ignored in Accept-Language HTTP header from "Task" to "Bug Report".
Feb 28 2019, 7:50 AM · MediaWiki-Installer, Patch-For-Review, I18n, UniversalLanguageSelector
Fomafix changed the subtype of T215737: The included enhanced RecentChanges has a different collapsible toggle button from "Task" to "Bug Report".
Feb 28 2019, 7:43 AM · MW-1.33-notes (1.33.0-wmf.25; 2019-04-09), Growth-Team, MediaWiki-Recent-changes

Feb 23 2019

Fomafix closed T216889: MediaWiki Extension WikiEditor README File typo as Resolved.
Feb 23 2019, 6:31 PM · MW-1.33-notes (1.33.0-wmf.19; 2019-02-26), Documentation, WikiEditor

Feb 18 2019

Fomafix added a comment to T177509: No in-browser spell checking in Firefox when "Wikitext syntax highlighting" beta feature is enabled with the 2010 wikitext editor.

Firefox 63 is affected by the accesskey problem. Firefox 64 is untested. Therefor I disabled the spellchecker for Firefox < 65 in PS5.

Feb 18 2019, 8:26 PM · Patch-For-Review, Browser-Support-Firefox, MediaWiki-extensions-CodeMirror

Feb 17 2019

Fomafix added a comment to T177509: No in-browser spell checking in Firefox when "Wikitext syntax highlighting" beta feature is enabled with the 2010 wikitext editor.

This means, that disabling of the spellchecking in Firefox is not needed anymore. https://gerrit.wikimedia.org/r/421349 removes the disabling of the spellchecking and can now merged. Maybe a version check of the exact Firefox version should remain to prevent that older Firefox versions accidentally insert accesskey characters into the content when the accesskey is used.

Feb 17 2019, 12:00 PM · Patch-For-Review, Browser-Support-Firefox, MediaWiki-extensions-CodeMirror

Feb 16 2019

Fomafix added a comment to T188607: Syntax highlighting disables middle button copy/paste in Firefox.

I can confirm a different behavior with CodeMirror and without CodeMirror on WikiText editor 2010 on Linux.

Feb 16 2019, 3:28 PM · Browser-Support-Firefox, MediaWiki-extensions-CodeMirror
Fomafix added a comment to T177509: No in-browser spell checking in Firefox when "Wikitext syntax highlighting" beta feature is enabled with the 2010 wikitext editor.

On Firefox 65 the problem with the accesskeys does not exist anymore. Mozilla probably fixed this problem in a version between 59 and 65.

Feb 16 2019, 1:14 PM · Patch-For-Review, Browser-Support-Firefox, MediaWiki-extensions-CodeMirror