Last modified: 2014-09-22 02:18:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T57463, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 55463 - LiquidThreads: Live preview of a reply should not use hacks
LiquidThreads: Live preview of a reply should not use hacks
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
LiquidThreads (Other open bugs)
master
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: javascript
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-08 10:32 UTC by Helder
Modified: 2014-09-22 02:18 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Helder 2013-10-08 10:32:07 UTC
Since Gerrit change #87917 the preview feature from LiquidThreads is not using AJAX. When I click on preview:
* It shows a popup saying "You have unsaved text open on this page. You may lose it if you go away from this page."
* If I confirm, it reloads the page instead of showing a spinner and updating just the content.
Comment 1 Krinkle 2013-10-08 17:37:39 UTC
This is because LiquidThreads is relying on core edit.preview.js to bind the click handler on the document.body.

I'll undo that part of the optimisation for now but this is really something that LQT should fix.

A click handler on an element by the ID of '#wpPreview' is not a public API and LQT has no business in trying to hijack that click.

The reason LQT could do this until now is because it basically reproduces most of the EditPage HTML (including the exact HTML IDs and classes on buttons and other form fields), except for the 'id="editform"' attribute on the form element.

At first I thought adding that ID wouldn't help (since LQT creates it dynamically and the core js would've already run) but actually it would fix it because LQT loads the core javascript manually. It does need to take care to re-use that element once bound, but that shouldn't be a problem.

In the short to medium term LQT developers should either not re-use this core javascript file and just write a few lines that do the same, or write a patch in core to make it a proper javascript interface.
Comment 2 Gerrit Notification Bot 2013-10-08 19:40:49 UTC
Change 88619 had a related patch set uploaded by Krinkle:
mediawiki.action.edit.preview: Fix for LiquidThreads hack

https://gerrit.wikimedia.org/r/88619
Comment 3 Helder 2014-01-30 18:10:36 UTC
Krinkle, should this be marked as FIXED or it requires some extra cleanup?
Comment 4 Alex Monk 2014-01-30 18:20:35 UTC
(Quoting comment #1)
> I'll undo that part of the optimisation for now but this is really something
> that LQT should fix.
Comment 5 Helder 2014-01-30 18:30:27 UTC
Should we change the bug title then?
(The live preview of a reply is working again)
Comment 6 Andre Klapper 2014-09-21 21:49:16 UTC
https://gerrit.wikimedia.org/r/#/c/88619/ was merged ages ago.

(In reply to Helder from comment #5)
> Should we change the bug title then?

Yes. But no idea to what. Feel free to go ahead. :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links