Last modified: 2014-07-04 16:32:40 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 T54091, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 52091 - VisualEditor: The read HTML should have hinting to allow full DOM copying (as opposed to just rich copying) from read mode into VE surfaces
VisualEditor: The read HTML should have hinting to allow full DOM copying (as...
Status: ASSIGNED
Product: VisualEditor
Classification: Unclassified
MediaWiki integration (Other open bugs)
unspecified
All All
: Low enhancement
: ---
Assigned To: Editing team bugs – take if you're interested!
:
: 52787 (view as bug list)
Depends on: 53784
Blocks: ve-richpaste
  Show dependency treegraph
 
Reported: 2013-07-26 12:47 UTC by John Mark Vandenberg
Modified: 2014-07-04 16:32 UTC (History)
8 users (show)

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


Attachments

Description John Mark Vandenberg 2013-07-26 12:47:54 UTC
As perhaps a simpler case of copy and paste from 'external sources', pasting richtext that copied from the same wiki should work seamlessly.

In many cases, the 'html' already has the metadata needed. e.g. the image, or text-with-wikilinks, even the categories, should be paste-able

https://en.wikipedia.org/wiki/Pelham_Parkway

With a tiny bit of additional html attributes, the navbox templates ({{Parkways in New York City}} & {{Bronx streets}}) could be copied as they are self-contained units - no parameter were used to invoke them.

Again with a bit of markup, the Infobox pasted into a VE session, but only the shell transclusion could set up - the parameters would need to be entered by the user in the VE.
Comment 1 James Forrester 2013-07-26 23:12:29 UTC
This is not simpler. This is the same. The problem is not taking in rich text (from any source), it's inserting it sanely into VisualEditor's ContentEditable surface, sadly. Merging.

*** This bug has been marked as a duplicate of bug 33105 ***
Comment 2 John Mark Vandenberg 2013-07-26 23:19:46 UTC
This is a separate problem James.  This is about copying from a non-VE wiki page on the same wiki.  That is very different from copying from another VE, or another website.  As I eluded to in my initial enhancement request, additional HTML needs to be emitted into the read version of the wiki page in order that a VE could pick up the name of the template to use when pasting it into a VE.
Comment 3 James Forrester 2013-07-26 23:26:48 UTC
(In reply to comment #2)
> This is a separate problem James.  This is about copying from a non-VE wiki
> page on the same wiki.  That is very different from copying from another VE,
> or another website.  As I eluded to in my initial enhancement request,
> additional HTML needs to be emitted into the read version of the wiki page in
> order that a VE could pick up the name of the template to use when pasting it
> into a VE.

Oh, sorry, I missed your comment about adding RDFa/etc. hinting to highlight what DOM elements are what.

"Tiny" is not remotely the correct word - this will require us to replace the entire read DOM with the same output as Parsoid provides VisualEditor, which is vaguely scheduled to be considered for research/analysis in about a year's time (this is so far off in the distance there isn't even a bug for it yet). Recasting.
Comment 4 James Forrester 2013-11-01 04:32:58 UTC
*** Bug 52787 has been marked as a duplicate of this bug. ***
Comment 5 Ed Sanders 2014-01-21 15:05:14 UTC
NB Firefox throws away RDFa properties when copying, so this won't be possible without JavaScript intercepting copy events, as it stands.

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


Navigation
Links