The "Edit source" tab loads/renders a little bit after the "Edit" tab, sometimes more noticeably so, sometimes less. Relatedly, clicking the "Edit" tab very early on sometimes invokes the wikitext editor.
It would be preferable for both tabs to be rendered simultaneously with the correct default behavior.
Version: unspecified
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Catrope | T52542 VisualEditor: Tab layout should be done from a top-loading module | |||
| Resolved | Krinkle | T52612 VisualEditor: Split mw.ViewPageTarget init from integration handling |
No, this bug is about the tabs at the top of the page (Read/Edit/Edit source), while bug 50540 is about the section-level edit links.
Re-titling slightly per discussion; the suggestion is now:
Sounds good. This could also fix bug 50402 at the same time I think?
What do you mean by "we display:none the former if the user doesn't pass the blacklist code"? What is the "blacklist code"?
pinkampersand.wikimedia wrote:
(In reply to comment #4)
What do you mean by "we display:none the former if the user doesn't pass the
blacklist code"? What is the "blacklist code"?
I believe James is referring to the part of VE that checks a user's browser and compares it against a "blacklist" of non-supported browsers. "display:none"-ing the VE edit tab thereby stops people from using VE if their browser's not going to let them.
One of y'all devs can correct me if I'm wrong here.
Shouldn't blacklisting occur much earlier (before actually messing around with any buttons at all?). Before having done *anything* actually?
I'm hoping for a definite answer by James (or another dev involved).
(In reply to comment #6)
Shouldn't blacklisting occur much earlier (before actually messing around
with any buttons at all?). Before having done *anything* actually?I'm hoping for a definite answer by James (or another dev involved).
Yes; that's bug 50608. We're re-working a whole bunch of items around the initialisation and integration code for VisualEditor right now - bug 50612 tracks that.
Ideally we'd alter the HTML using a PHP hook, then have a top-loading module that just conditionally adds some CSS to make the HTML generated by the PHP hook display correctly. That should allow us to get rid of the flashing tab behavior.
Change 71929 had a related patch set uploaded by Krinkle:
Split off setup from the rest of mw.ViewPageTarget
Change 71929 merged by jenkins-bot:
Split off setup from the rest of mw.ViewPageTarget
(In reply to comment #10)
Change 71929 merged by jenkins-bot:
Split off setup from the rest of mw.ViewPageTarget
This introduces a top-loading module, but still does the tab layout from document ready, which means there's probably still is a flash. What we should really do is change the HTML from PHP, per comment 8.
Change 77165 had a related patch set uploaded by Catrope:
Move edit tab generation into PHP and make it more configurable