Page MenuHomePhabricator

VisualEditor: Open button in link inspector should be disabled when the link target field is empty
Closed, ResolvedPublic

Description


Version: unspecified
Severity: minor

Details

Reference
bz70015

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:42 AM
bzimport set Reference to bz70015.

Right now, when you open link inspector and keep the link target field empty, you will still be able to click on "Open" button as it remains active, though it serves no purpose.We should disable it in this case

gerritadmin wrote:

Change 156582 had a related patch set uploaded by Alex Monk:
Link target input widget: Make '' an invalid link target

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

gerritadmin wrote:

Change 156582 merged by jenkins-bot:
Link target input widget: Make '' an invalid link target

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

The "Open" button is now getting disabled when you clear the link target name , but if you just open the link inspector in any empty line and there is no link target name specified yet , the "Open" button still remains enabled

I uploaded Gerrit change 157017 to resolve that issue, and Roan just merged it. I forgot to link it to this bug, sorry!

Created attachment 16315
Screenshot

hmm..but I still see that button as active :/

Attached:

Screen_Shot_2014-08-29_at_1.51.03_PM.png (478×779 px, 112 KB)

Works for me. Gerrit change 157212 should've sent my fix to beta labs.

Yeah, just started working for me! Marking as Resolved .

Again in production, the "open" button remains enabled when I open a link inspector in a blank line without selecting a text.I will wait for a while to see whether it gets started working automatically like it did in Betalabs.Reopening it for now.

I just tested this on MediaWiki.org and it seems to have been fixed. . .

So the first patch set I made (to deal with existing links when you clear the target page) should be deployed to all Wikimedia wikis. But the second one (per Rummana's comment 4) was merged a day later which just happened to put it on the next deployment version (so it should be another week).

Verified the fix in Production