Page MenuHomePhabricator

Mobile web errantly showing edit pencil with JS disabled
Closed, ResolvedPublic

Description

The mobile web presentation should not, for the time being, show the edit pencil when JS is disabled. In the future we may want to explore supporting the option to get to plain wikitext editing, but for now it's suboptimal to take the user to a page that says it's redirecting, but never redirects the user. This appears to be a regression that slipped through the cracks.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 10 2016, 4:51 PM
dr0ptp4kt triaged this task as High priority.Aug 10 2016, 4:51 PM
dr0ptp4kt updated the task description. (Show Details)
dr0ptp4kt renamed this task from Grade C errantly showing edit pencil on mobile web to Mobile web errantly showing Grade C edit pencil.Aug 10 2016, 4:56 PM
dr0ptp4kt updated the task description. (Show Details)
phuedx renamed this task from Mobile web errantly showing Grade C edit pencil to Mobile web errantly showing edit pencil with JS disabled.Aug 10 2016, 5:17 PM
phuedx updated the task description. (Show Details)

Let's fix this by adding an inline style that we remove with JS and SWAT deploy ASAP.

bmansurov raised the priority of this task from High to Unbreak Now!.Aug 10 2016, 5:18 PM
Restricted Application added subscribers: Luke081515, TerraCodes. · View Herald TranscriptAug 10 2016, 5:18 PM

For the record I don't agree this is unbreak now (I'd say high as it doesn't cause fatals or break the primary reading experience), nor that it needs a SWAT. It's unsightly yes and we should fix it asap but I actually think it is going to be useful to get a sense of how many users want to edit without JS for T125174. cc @Jdforrester-WMF

jhobs added a comment.EditedAug 10 2016, 5:44 PM

@Jdlrobson It doesn't break the reading experience per say, but if a user taps the icon they reach a page with an infinite "Loading editor" message. I'd say that warrants the priority, since we can potentially fix it before the cache clears, avoiding most users ever experiencing it.

Jdlrobson added a comment.EditedAug 10 2016, 5:53 PM

Tapping an edit icon is leaving the reading experience. I agree it sucks but with JS disabled it tells you that editing is unavailable. You can click back to exit or follow the return link.

@MBinder_WMF sounds like a retro item - what does unbreak now mean.
It's worth noting many users subscribe to unbreak now bugs so it should really be used lightly.

greg added a subscriber: greg.Aug 10 2016, 6:02 PM

@MBinder_WMF sounds like a retro item - what does unbreak now mean.
It's worth noting many users subscribe to unbreak now bugs so it should really be used lightly.

Also, I check all UBN! tasks at least once a day to make sure none fall through the cracks.

I'd prefer if you could reduce it to High if you don't plan to fix this now (as per the priority name). Or, fix it now and deploy it.

dr0ptp4kt lowered the priority of this task from Unbreak Now! to High.EditedAug 10 2016, 6:18 PM

Downgrading to High, but please do pull this in first to the sprint if looking for work, followed by the Hovercards 8 hour spike.

Jdlrobson moved this task from To Do to Doing on the Reading-Web-Sprint-78-Terminal-Velocity board.

Change 304297 had a related patch set uploaded (by Jdlrobson):
Hide edit and watch icons when JS disabled

https://gerrit.wikimedia.org/r/304297

this is is one of the rare occasions I suggest using !important :)

Change 304297 merged by jenkins-bot:
Hide edit and watch icons when JS disabled

https://gerrit.wikimedia.org/r/304297

phuedx closed this task as Resolved.Aug 12 2016, 9:24 AM
phuedx added a subscriber: phuedx.

This LGTM.

I tested this on our staging server with the old action bar and the new action bar ($wgMinervaUsePageActionBarV2 set to true), with and without JavaScript enabled in Chrome (52.0.2743.116) on OS X El Capitan (10.11.6) and an emulated Nokia N900 Maemo.

Thanks, everyone.