User Details
- User Since
- Oct 27 2014, 6:03 PM (211 w, 4 h)
- Availability
- Available
- IRC Nick
- edsanders
- LDAP User
- Esanders
- MediaWiki User
- ESanders (WMF) [ Global Accounts ]
Today
On further investigation it looks like the API is only returning one result for these queries, so must be a config issue with the beta cluster, as suspected.
I was seeing the single result on beta cluster before merging, so I assume it's a config issue. The patches are CSS only, so unlikely to be the cause of hiding a result.
Yesterday
It is also possible to migrate to ES6 promises while maintaining a jQuery.Deferred-like API. This would allow use to remove the dependency more easily, then switch over to a native Promise API in a piecemeal fashion (if we want to).
Fri, Nov 9
To do that would mean making them BranchNodes, instead of ContentBranchNodes, and so affects a lot of things..
Thu, Nov 8
This is also the size non-OOUI ovelays in MobileFrontend. Seems like a pretty big change with lots of knock on effects, but in principle I think we should be considering if we can get away with smaller buttons. By comparison the tools in GoogleDocs mobile app are much smaller than ours.
This should result in a very significant improvement to mobile page load times.
We should check with @Neil_P._Quinn_WMF that we have reasonable page load timings for Mobile VE before we deploy any improvements.
With network throttling:
- Fast 3G: Not much change, metadata takes 800ms and HTML takes 600ms. As metadata is the slower of the two in parallel this is only 80ms slower than above.
- Slow 3G: Metadata take a similar amount of time, ~2000ms.
Wed, Nov 7
Now 3876/4745 (81.69%) 🎉🎉🎉
Interestingly this fails on the live site, but I can't reproduce locally..
Note that most of our users are on MobileSafari11/12 . MobileSafari9 is <3% of 37%.
After:
We set the cursor offset to [1,1] (or the first content position, so by current behaviour it should scroll to the top of the page in all browsers.
Do we plausibly still need a max height anyway?
Tue, Nov 6
The citoid service will try both. If it gets results from both, it gives two results. Citoid picks up only the first link though.
Edge cases:
- Text contains a link, do we search for the link or the text, or give up? e.g. <ref>[http://news.example.com/title-of-article Title of Article]</ref>
- Text contains multiple links, do we pick the first link, or use the text, or give up?
- Citation contains another template we don't recognise, do we use the generated output or give up? e.g. <ref>{{other-link-generator|param}}</ref>
- Citation contains template and text, do we ignore the template, or give up?, e.g. <ref>Title of Article {{from-this-news-site}}</ref>
Are there particular patterns we should look for to blacklist/whitelist, or should we just provide the "convert" button for every non-template citation?
I edited my comment, this looks like expected behaviour...
It's a bit against convention to even have icons in a dropdown (as in Apex the selected item uses a check icon). If we really want to show the user what each mode looks like we should probably use larger images and a different widget.
After:
The patch will fix renderings in infoboxes and other non-editable areas, but there will continue to be slight rendering differences between read mode and edit mode. I don't really want to change that as there may be a good reason for using word breaking by default in edit mode.
The parent contentEdtiable=true changes the word-break behaviour (even though the infobox is ce=false). Think we've seen this before, probably a browser bug but not a big issue.
This doesn't appear to be a problem on WMF wikis, so lowering priority. Maybe it depends on which search provider you use on your wiki?
Looks like we had code in to put separators but it wasn't working as intended, so marking this a regression instead.
After separator patch:
After above patch
window-clipped:
I have a preference for having a default icon for non-registered templates.
Can't reproduce this...
My personal preference is not to make a decision for the user
We deliberately strip external links from external paste sources so that external links don't get accidentally added to Wikipedia articles.
Mon, Nov 5
This has not been an issue on WMF wiki as the TemplateData extension is loading this module for us. Filed T208765 as a follow-up.
Yes.
The reason for this is that tab/shift+tab perform actions in some contexts in VE, specifically in a list they change indentation, and in table selections they cycle through cells. It is easy enough to allow change focus to work only in non-list/non-table contexts, but I'm not sure this is the greatest solution.
This is true of all VE surfaces, include the TargetWidgets found in media/gallery dialogs:
Is this still present in Safari? If the browser vendors have fixed it for us we should probably just close.
After:
