Right, so I know what the reason is, I think. The idea behind not having holes for geomasks was that holes with more than 1 of those thick red line holes, make for very messy shapes that often heavily obscure that part of the map, especially for the thumbnails.

@Jdlrobson That's a lot of issues combined. In general we've seen this when scripts either override $ itself (often accidentally not realising they are using globals), or with property iterators on objects that accidentally override/modify properties.

Found this nice resource on storage access technical details, if anyone ever needs to work with that: https://github.com/rchild-okta/itp#storage-access

In T226797#6866173, @SerDIDG wrote:

That seems very wrong, CentralAuth expose my ip address when i try to use mw.ForeignApi in js to read some not user specific data from Wikidata project. I'm logged in at ruwiki.

@Volker_E btw. this element also would really benefit from setting overflow:hidden to reset the block context to avoid issues with floating elements (much like we do for H#). en.wp has had this in it's Common.css for years.

We can likely add firefox to this as their ETP becomes full state partitioning
https://hacks.mozilla.org/2021/02/introducing-state-partitioning/

eh question.. enable line number specifically for Template namespace ? Or for all non-CodeEditor namespaces ?

@MSantos Just a small note regarding map loading performance. We currently use a single hostname for serving up tiles. Especially when multiple tiles are in the map (fullscreen), the browser tends to parallellize no more than 5 download requests for png image per host at a time. In my experience this is actually the biggest delay when loading any sort of larger map view that includes multiple tiles (fullscreen). This is also why on the old toolserver we used to have tiles.a.toolserver.og, tiles.b.toolserver.org and tiles.c.toolserver.org and why the leaflet style url specification allows for multiple domains.

i'm guessing this can be closed

This is not a breaking out of container problem however. It's a "desktop site used on mobile" problem. For desktop sites, the mobile browsers emulate a larger screen. If the content is asking for more width, it will provide you more width (up to a maximum) and/or shrink other content. Since here a lot of width is requested, you will see the page at its maximum zoomed out level, with the maximum amount of width.

In T235554#6708656, @Ciencia_Al_Poder wrote:

There are reports of users fixing this by commenting out the line $response->header( 'Content-Encoding: identity' );

See this topic

In T201597#6655990, @sdkim wrote:

Is it correct to assume that Edit Notices have never existed on the mobile-versions of this editing experience? If so, this sounds like it would have to be a conversation with the platform team to ensure that we make Edit Notices in the future extend to all applications, agnostic of whether someone is on desktop or on a mobile app.

I haven’t investigated this particular case, but I believe that the point is made in another ticket somewhere as well. The output of mapframe generates a lot of wiki content because it encodes a lot of information after template expansion. This is inefficient and can quickly inflate the overall size of the page, without editors noticing it.

This proposed change seems reasonable, but if I’m not mistaken, that codepath is shared between the static map generation and the Front-end... if we generate ‘half’ rendered static maps, then how long would these be cached (without a method to purge them) @MSantos ?

So this is a report about the 'size of diffs' of revisions as shown in the history of an article, using the Mobile web interface.

Pretty sure it has invalid json...we should probably have a proper user facing error for that

That data page itself throws an error. Seems the contentmodel is set to wikitext

no one seems to know what exactly this is about, so close

This should be pretty easy in theory for the 'fresh' script but...... @MSantos eeh.. any idea how to puppetize a database scheme change like this ?

closing as invalid as it seems to have been an issue with the way the api was used by the consumer.

This would indeed be very cool, but it is also a very specific feature and one that is not easily possible within the current OpenStreetMap dataset and architecture (although some attempts have been made at this in the past). As such, it would seem extremely unlikely that we will implement this.

@MSantos this seems like a reordering of the deploy street broke the /geoline endpoints of maps.wikimedia.org ?

Or just print to pdf and copy it from the pdf

WMF Browser requirements are most definitely higher now.
For Safari

• iOS 9
• MacOS X 10.11

Android 4.4.2
Firefox i think is 31+ ?? not sure
Chrome: probably still pretty old versions, but ssllabs doesn't go that far back.

Not sure which Editor the user has here, but it sure isn't WikiEditor

We should probably also update https://wikitech.wikimedia.org/wiki/HTTPS with the new status quo

I remember that [[#jump-to-nav]] in the past was also used as an anchor link sometimes instead of [[#top]]. Might be another impact to look out for.

@Jdlrobson this change to mw.util creates errors when someone makes it lose it's context i think.

I'm resolving this, as most of this is fixed and separate tickets for any remaining issues exist or should be filed.

See also T246925

mapOutputToInputTime is part of ogvjs

This issue is an issue in the ogvjs decoder. It is possible that this would apply to both Kaltura and VideoJS players.

This issue is an issue in the ogvjs decoder. It is possible that this would apply to both Kaltura and VideoJS players.

@Wargo Because i didn't have much time to work on it, and trying to get it through review was a pain.

I find the lack of action on this ticket stunning. This is exactly why I said two years ago to completely cut off en.wp from these features, so that we wouldn't have this mess right now.

1: yes this is ITP and related policies
2: Firefox has something similiar with Enhanced Tracking Protection (ETP) but this can be bypassed by the user, unlike Safari
3: google chrome will be following with blocking 3rd party cookies

It seems that the inline diff is now in the diff table, but this causes it to overflow ?
Example: https://en.m.wikipedia.org/wiki/Special:MobileDiff/975914133?diffmode=source

Remember that we are also on a version of ffmpeg that is probably not brand new. It might just be that there is a bug that got patched since.

Was looking into this a bit. My first idea was to just dump them with status->warning inline, but unfortunately, due to the loose JSON schema used, validation errors can be incredible long that way. For example in this specific case of a missing Q in the id...

Not sure when it was restarted, but all seems to be working here

In T260993#6404706, @Huji wrote:

Does that mean you oppose the newer solution, in which duplicating [dir=xxx] selector results in the desired behavior?

Yes this should be reverted (and documented) or changed to !important.

I'd advocate disabling things like this, based on wgPageContentModel. While namespaces have a default contentmodel, that doesn't mean mean that namespaces always have their default content model.

CodeEditor/CodeMirror can be removed, because those are only in the language-mode definition for highlighting, not in the extension's php code.

Desired improvements that people have informed me about or that I want

ffmpeg has an option -nostdin .. maybe we should add that to our command line spec as well ?

@Jarekt I think you mean this page? https://commons.wikimedia.org/wiki/Commons:Machine-readable_data ?
And my script will show you the values that the apis have collected: https://commons.wikimedia.org/wiki/User:TheDJ/datacheck.js

No, it’s the line below that. Maps domain is what u give access to, referrer is what is used to check what gets access.

@Zache for the login issue I have created: T260538: Monumental's OAuth integration is broken due to tools.wmflabs.org -> toolforge.org transition

This is already documented as not supported: https://www.mediawiki.org/wiki/Manual:Messages_API#Feature_support_in_JavaScript

Deployed as https://zonestamp.toolforge.org
Script at: https://github.com/hartman/zonestamp-toolforge