I live in the United Kingdom GMT/BST(UTC+0, UTC+1)
I have autism.
🇪🇺 🇬🇧
I live in the United Kingdom GMT/BST(UTC+0, UTC+1)
I have autism.
🇪🇺 🇬🇧
In T380791#10355323, @SomeRandomDeveloper wrote:This was added in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/1071145 . The hook was added recently for 1.43 so the version requirement of Extension:Translate probably needs to be raised to 1.43.
There's no project for OpenLayers tho.
In T216508#8808277, @Yaron_Koren wrote:@Paladox - sorry for the extremely long delay on this; OpenLayers is now already up to version 7, I believe. Is this an issue for the Page Forms extension, though, or for the OpenLayers extension?
This was fixed 5 months ago. Closing as resolved.
Just gonna decline as I guess it's expected extensions handle this?
Think I fixed HAWelcome with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/HAWelcome/+/1095303 which I guess makes it a extension problem?
Or we can wrap https://github.com/wikimedia/mediawiki/blob/master/includes/title/Title.php#L906 in sanitizeIP.
I'm not entirely sure what the fix would be. We can either remove that piece of code or we could do use prettifyIP()?
This is our ip I'm using to demonstrate the problem but it's HAWelcome that was having the problem with some users ip. I cannot share that ip for gdpr reasons, hence why I'm using our ip to demonstrate.
Nvm, it's correct
Seems I got it wrong.
Think this may be able to be replaced with attemptSave().
This looks similar to T378006 which there's a patch for https://github.com/wikimedia/mediawiki/commit/8f7b4abd751f9f4e402b104f19b1e48559d7834f
In T380223#10333496, @Yaron_Koren wrote:What versions of Page Forms and Semantic MediaWiki are you running? Most importantly, does your SMW code already include that fix?
Support for large file objects support should probably be added to ->quickStore.
Or we can use something like https://github.com/wikimedia/mediawiki/blob/master/includes/jobqueue/jobs/ThumbnailRenderJob.php#L173. Prevent retry’s when it errors out with revision not current? As it implies a new job has been created already?
https://github.com/wikimedia/mediawiki/blob/master/includes/jobqueue/jobs/RefreshLinksJob.php#L505 Should return false. Then https://github.com/wikimedia/mediawiki/blob/master/includes/jobqueue/jobs/RefreshLinksJob.php#L381 should check for false and then return false and keep the check for null. https://github.com/wikimedia/mediawiki/blob/master/includes/jobqueue/jobs/RefreshLinksJob.php#L288 Should check for false and then return true.
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1088716 fixed it, closing this as resolved.
Seems https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1088716 this will fix it?
In T379342#10305250, @Umherirrender wrote:Using wikimedia/services in version 3.0.0 together with wikimedia/scoped-callback version 5.0.0 does not work as the bump in 26dbce1abbaf4ebf856a1c6d2a79d9ea130ad31d is not released yet (tracked via T379384)
TemplateStyles requires wikimedia/css-sanitizer version ^5.1.0 || ^5.2.0, your composer seems to use 5.4.0 released with 7d0a15de3d234fd083aa6b0cb3fb6ac817089ece including the wikimedia/scopedcallback bump. But older scopedcallback are also allowed. composer should install the compatible version for scoped callback.
Possible fixes:
- Release css-sanitizer 5.4.1 with scopedcallback 4.0.0 to remove 5.0.0 and release css-sanitizer 6.0.0 afterwards as it contains breaking change
- Use ~5.1.0 || ~5.2.0 in TemplateStyles to avoid update to 5.4.0 (this does not help existing installs when running composer update)
- Release scoped callback 5.0.1 without breaking change?
Running composer update right now on master also brings in this breaking change when not using the merge plugin, needs bump of services in core to fix.
Think this will impact MW 1.42 as well?
Oh, it's because of ^5.1.0 https://github.com/wikimedia/mediawiki-extensions-TemplateStyles/blob/REL1_43/composer.json#L4
Seems https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1051869 also brought in a broken word for en-gb.
If I works for you on mw 1.42 then it's safe for you to merge.
I feel like that will work.
In T376549#10205492, @Yaron_Koren wrote:Hi - what version of Cargo? For what it's worth, the current/old code works fine me, on MW 1.43.
Running MediaWiki 1.42 and php 8.2
I think this is fixed with https://github.com/GerritCodeReview/gerrit/commit/380b6a844ce52556d905322e675fdf99cefe1bcd
I've fixed the url with https://gerrit-review.googlesource.com/c/gerrit/+/432038
For some reason the fix didn't merge up, so it's not in 3.10. I've cherry picked the fix to the branch here https://gerrit-review.googlesource.com/c/gerrit/+/431657.
I added support for diff3 to rebasing/cherry-picking in the UI. https://gerrit-review.googlesource.com/c/gerrit/+/431417
Backported to gerrit 3.10 here: https://gerrit-review.googlesource.com/c/gerrit/+/431417
Found the commit that fixes this https://gerrit-review.googlesource.com/c/gerrit/+/393975. This was incorrectly reverted in https://gerrit-review.googlesource.com/c/gerrit/+/395140 by mistake. I've re-done it with https://gerrit-review.googlesource.com/c/gerrit/+/429837.
In T358762#9888333, @hashar wrote:Fun thing I have noticed is the <a> element shallows the closing bracket and the href contains the closing bracket. So it is more complicated than just a ; being added. I think the link is generated by:
polygerrit-ui/app/utils/link-util.tsfunction createLinkTemplate( href: string, displayText: string, prefix?: string, suffix?: string ) { return `${ prefix ?? '' }<a href="${href}" rel="noopener noreferrer" target="_blank">${displayText}</a>${ suffix ?? '' }`; }Which would be fed:
prefix < href https://example.com> displayText https://example.com> suffix ; The method is apparently called solely for processing commentlink which are regex feeding the above function. Maybe one of our configured comment link is the cause of the issue?
Looks like the repo is now https://github.com/googlefonts/roboto-classic and not https://github.com/google/roboto
Did you clear your browser cache? it works for me.
In T362269#9873138, @Aklapper wrote:In T362269#9714170, @Paladox wrote:Does this work for you now?
@Paladox: Has something related changed server-side in the meantime?
In T344891#9852140, @Aklapper wrote:In T344891#9811339, @Paladox wrote:This will be fixed with T365328.
On some cheap Android phone it initially looks like this:
It was not super obvious that I have to drag the viewport sideways to get this:
Yeh, it’s a hack. I’ve fixed it on the master branch of Gerrit by creating a mobile view. Please visit https://gerrit-review.googlesource.com/q/status:open+-is:wip to see what it’s like and do give feedback!
Oh... I have the permissions to create one. Have done so here: https://github.com/highlightjs/highlightjs-epp
I'd ask them to create a hjs repo for you similar to highlightjs-closure-templates so that we can include it in gerrit.
Does this issue still happen to you?
This will be fixed with T365328.
In T364484#9781195, @thcipriani wrote:I note the review for this change mentioned making the message longer: https://gerrit.wikimedia.org/r/c/operations/puppet/+/1027726
I think that we would *use* https://github.com/GerritCodeReview/gerrit/blob/4f82b6d02ac5517e8db3771b17fa28da0a0b9677/polygerrit-ui/app/models/checks/checks-model.ts#L158 in https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/gerrit/+/refs/heads/deploy/wmf/stable-3.8/plugins/wm-checks-api.js#631.
In T214631#9746166, @thcipriani wrote:Guessing this no longer works since gerrit moved to lit, is that right @Paladox ?
(also, seems we've undeployed the wikimedia gerrit plugin judging from our latest release)
I do wonder how trivial this would be to implement as a new js plugin? This is something that someone mentioned in the latest developer satisfaction survey comments.
I’ve disabled it. Thanks.
Is this still an issue?
Is this still an issue (also a + is that gerrit supports rebasing chained changes now via the UI).
Is this still an issue?
(This was discovered by someone else)
The above shows then end “. It’s just not obvious as it has a similar colour to the tabs when zoomed out but is blue zoomed in.
This appears to be because items are being pushed out of screen. I did a hack https://gerrit-review.googlesource.com/c/gerrit/+/420278. It's an ugly hack but it does the job. The better fix and something I'm pushing and looking at is to create a mobile optimised header that pushes these drop downs to a side bar (or aka hamburger).
I think this may be fixed in gerrit 3.9 based on testing locally. I can't reproduce on master but I remember work on the diff screen being done for that release.
Oh... It misses the end " bit.
This seems fixed at least scroll bars show for me now.
You can search state:active or state:read-only in the UI. Doesn't seem to support hidden.
In T343471#9722290, @Jdforrester-WMF wrote:In T343471#9722276, @Paladox wrote:Does this still not work (gerrit is now on 3.8)?
AIUI the web editor in gerrit is broken since we moved to 3.8, so I don't think we can test yet.
Does this still not work (gerrit is now on 3.8)?
Does this work for you now?
I think you need to clear your browser cache. It works for me and Polymer isn't use any more for the codemirror gerrit plugin.
Closing as resolved. I'm not sure what the process is for opening the task to public? Is it once all those changes were merged that it can?
I've merged it and back ported it to all the stable releases up to 1.39 (so 1.41 & 1.40)
Thank you for reporting! Would you mind doing the patch on Gerrit and I’ll +2 it as soon as you’ve done it please?
From what I remember it's https://github.com/GerritCodeReview/gerrit/blob/stable-3.7/polygerrit-ui/app/elements/change/gr-change-view/gr-change-view.ts#L629. I last took a dive years ago so I'm a little fuzzy. But I do remember it was within there.
This is fixed in gerrit 3.9. This is to do with the migration to lit that to get it working needed to use the change model. The changes couldn't be back-ported because they are big and would require a lot being backported.