Last modified: 2013-12-17 02:20:54 UTC
This used to work by using localStorage, but was removed due to problems with stringifying and parsing annotationSets.
Assigning to myself.
In order to support this functionality we need to develop some sort of annotations serializer and deserializer. Also, question to the other of this ticket: Do you mean copying content from VisualEditor opened in one tab to VisualEditor opened in another tab of the same browser (Chrome for instance)?
(In reply to comment #2) > Also, question to the other of this ticket: Do you mean copying content from > VisualEditor opened in one tab to VisualEditor opened in another tab of the > same browser (Chrome for instance)? This is still not working: 1. Open two different articles with VisualEditor. 2. Copy or cut content from one and paste it to the other one. Format is lost. Links are lost. Not worth even trying in an average wiki page. This is a relatively frequent action when cleaning, reorganizing archiving content in articles.
*** Bug 50421 has been marked as a duplicate of this bug. ***
Change 86664 had a related patch set uploaded by Esanders: Rich paste https://gerrit.wikimedia.org/r/86664
Change 86664 merged by jenkins-bot: Rich paste https://gerrit.wikimedia.org/r/86664
As reported at [https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content.3F], this is clearly not yet fixed. Testing at MediaWiki shows that copying between VisualEditor pages (both within MediaWiki, and from enwiki to MediaWiki) gives very poor results. I have made four tests, none of them anything extreme (only one section header and text, no images, templates, ...), and none of them gave a satisfactory result.
James Forrester, get lost. Why do you reclose a bug as resolved -fixed without any improvement or comment, when people take the time to test this, report their findings, and show where the problems are? The least you can do is explain why this is resolved - fixed despite my remarks; the best you can do is test this, correct it, and only then close it as fixed. How many times will you make the same mistakes, how often will you close bugs as duplicates when they are not, as fixed when they are not, or present things as finished when they aren't even tested? Please change your approach to this or leave it to people who seem to be more competent or less defensive. You are not doing yourself, WMF, or Wikipedia a favour by your continued behaviour wrt VisualEditor.
> Why do you reclose a bug as resolved -fixed without any improvement or comment Because the functionality to copy and paste from other VE instances exists with the given patch having been merged, so this request is FIXED. This bug report never was about "Implement functionality to copy and paste from other VE instances and make sure that it works in 100% of all cases". Software always has issues. But the request in this bug report has been fixed. Hence please create separate followup bug reports on issues that don't work and provide exact steps to reproduce. Comment 7 does not have steps to reproduce. Thanks for your help!
But can't we expect new functionality to work sometimes? ''Every'' test I have done produced errors. You could copy and paste before this "fix", it didn't give any layout though. With this fix, you get some layout, and a lot of botched layout. I really can't believe that any of you believe this "fix" is sufficiently reliable, stable, mature to be implemented in live environments. Sometimes, like here, ''not'' having a feature is a lot better than having an extremely poor attempt at one. I don't expect it to work 100% in all cases, but I do expect it to work 100% in some cases, and 95% in most cases. I don't believe this can truthfully be claimed of this. As for "provide exact steps to reproduce": RTFM. I have given a link to the many tests I have done, I have described there what goes wrong. I have only received evasive or plainly incorrect answers from WMF people there. I am not going to repeat all of that here, you can just as easily follow the link I provided and try do to the same. No thanks for your (WMF collective) help.
Wikifram: Sorry, I won't read through the entire https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content.3F - summarize clear testcases in Bugzilla in separate followup tickets to keep things constructive, change your passive-aggressive tone, keep this ticket closed as FIXED (as functionality exists but obviously is extremely error-prone for your testcases), and discuss high-level stuff refering to general testing on the mailing list instead. Thanks.
(In reply to comment #11) > Wikifram: Sorry, I won't read through the entire > https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content. > 3F - > summarize clear testcases in Bugzilla in separate followup tickets to keep > things constructive, change your passive-aggressive tone, keep this ticket > closed as FIXED (as functionality exists but obviously is extremely > error-prone > for your testcases), and discuss high-level stuff refering to general testing > on the mailing list instead. Thanks. My tone isn't passive-agressive, it is simply agressive, as in thoroughly fed up with the way the WMF handles things. I love it though that theDJ has added a ticket that blocks this one, but that you closed it again nevertheless. I am not interested in discussing things on the mailing list, I am discussing it at enwiki which has the largest and least biased audience of all public discussion places (compared to MediaWiki, which has a rather more slanted and smaller audience, Foundation, where there are no public discussion spaces, and Bugzilla, which is not suited for this). Closing tickets without any explanation, like Product Manager Forrester did, is passive-agressive and completely unconstructive though. Perhaps you can lecture him on these things instead. My posts have been constructive, trying to improve Wikipedia and VE, but the format and tone hasn't been to your liking. Tough luck. If you wan to know what is wrong with this "feature", either read the enwiki thread or (better still) test it or get your team to test it thoroughly, but don't expect me to repeatedly seek the shabby treatment the WMF people routinely handle out to critics, by submitting new bugs about this.
(In reply to comment #12) > (In reply to comment #11) > > Wikifram: Sorry, I won't read through the entire > > https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content. > > 3F - > > summarize clear testcases in Bugzilla in separate followup tickets to keep > > things constructive, change your passive-aggressive tone, keep this ticket > > closed as FIXED (as functionality exists but obviously is extremely > > error-prone > > for your testcases), and discuss high-level stuff refering to general testing > > on the mailing list instead. Thanks. > > My tone isn't passive-agressive, it is simply agressive, as in thoroughly fed > up with the way the WMF handles things. I love it though that theDJ has > added a > ticket that blocks this one, but that you closed it again nevertheless. > > I am not interested in discussing things on the mailing list, I am discussing > it at enwiki which has the largest and least biased audience of all public > discussion places (compared to MediaWiki, which has a rather more slanted and > smaller audience, Foundation, where there are no public discussion spaces, > and > Bugzilla, which is not suited for this). > > Closing tickets without any explanation, like Product Manager Forrester did, > is passive-agressive and completely unconstructive though. Fram, I closed this without comment because we'd already discussed this, and it didn't seem like a worthwhile expenditure of my time or yours to re-hash the issue when we already agreed about things. I'm sad that you think I did it out of malice. AGF clearly doesn't apply to your attitude. :-( Please be less aggressive in future.
(In reply to comment #13) > Fram, > > I closed this without comment because we'd already discussed this, and it > didn't seem like a worthwhile expenditure of my time or yours to re-hash the > issue when we already agreed about things. I'm sad that you think I did it > out > of malice. AGF clearly doesn't apply to your attitude. :-( Please be less > aggressive in future. No, I'll only get more aggressive, just read my last post at enwiki or my next post here, which will be a link to enwiki. "We'd already discussed this"? You mean your replies at [https://www.mediawiki.org/wiki/Talk:VisualEditor/status]? No, I don't see where we actually agreed upon things. You were pinged about the enwiki discussion as well, which contained further examples. But I don't said you did it out of malice, there are a number of other possible reasons, including (but probably not limited to) laziness, incompetence, stupidity, or a hopefully well-founded fear of losing your job after the umpteenth VE fiasco.
[https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=585650020&oldid=585645740] This thing is so not ready that it is laughable to claim otherwise. I would seriously urge you to keep this on open now, read and check all the comments (bug reports), and only then come back. This is more serious than any of you seems to understand. THIS FIX IS ABSOLUTELY NOT READY TO BE DEPLOYED. Read the fucking linked section, [[en:Wikipedia:VisualEditor/Feedback#Who needs bugs when you get "fixes" like this?]], don't bury your heads in the sand.
Your attempts to re-write history notwithstanding, Fram, this is and remained fixed. If you edit war again, I imagine someone will end up taking your edit rights away. Please stop.
Oh, my edit rights at Bugzilla? I'm scared now. What will I do without the possibility to edit Bugzilla? I imagine that if you continue to bury your head in the sand, someone will take away your job, but my imagination and reality sadly don't always match. Have you actually looked at and read (and understood) the linked enwiki thread? And you can straight-faced claim that this is "fixed"? This is comparable to "operation successful, patient dead".
(In reply to comment #17) > Have you actually looked at and read (and understood) the linked enwiki > thread? And you can straight-faced claim that this is "fixed"? I am aware that this bug, though fixed, does not encompass the entirety of what we want to see. There are other bugs, many of which we are trying to fix but are being distracted by people who think it's productive to edit-war on Bugzilla and sling insults and threats rather than actually engaging. If you had bothered to ask, rather than just assume, we could have pointed this out before you got so very excited. But you seem more content to scream than talk, and then act surprised when we choose to spend our time more productively.
(edit conflict) As for rewriting history, I reopened this here with the comment "As reported at [https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content.3F], this is clearly not yet fixed. Testing at MediaWiki shows that copying between VisualEditor pages (both within MediaWiki, and from enwiki to MediaWiki) gives very poor results. I have made four tests, none of them anything extreme (only one section header and text, no images, templates, ...), and none of them gave a satisfactory result." Can you indicate where you replied to this comment and/or adressed the issues I highlighted in them? Are you seriously claiming that your comment at the Status page was a reply (never mind a sufficient reply) for problem reports like what happened [https://www.mediawiki.org/w/index.php?title=User%3AFram%2FSandbox&diff=837324&oldid=837321 here]? You didn't at least think about retesting this when you thought that this was "resolved"? It still happens, FYI. And when I reopened this, you didn't think that just perhaps I didn't believe that this was resolved onwiki or offwiki? I have pointed out countless bugs, probably more than anyone else the last half year: perhaps it is time you start taking them seriously, and consider that I may have a point, instead of blundering on blindly.
(In reply to comment #18) > (In reply to comment #17) > > Have you actually looked at and read (and understood) the linked enwiki > > thread? And you can straight-faced claim that this is "fixed"? > > I am aware that this bug, though fixed, does not encompass the entirety of > what > we want to see. There are other bugs, many of which we are trying to fix but > are being distracted by people who think it's productive to edit-war on > Bugzilla and sling insults and threats rather than actually engaging. > > If you had bothered to ask, rather than just assume, we could have pointed > this > out before you got so very excited. But you seem more content to scream than > talk, and then act surprised when we choose to spend our time more > productively. "Though fixed". Right... "Does not encompass the entirety of what we want to see" is newspeak for "actually screws up nearly every edit"? "People who think it is productive to edit-war on Bugzilla and sling insults and threats rather than actually engaging"; history has shown that complacency isn't productive with you (plural), so another approach is needed. "Actually engaging"? The section about this bug and these problems has been open for days at enwiki, I have done ''all'' the work on it, I am the only one that actually tested this bugfix (and the rest of the deployment as well, clearly). Your "engagement" was a hardly relevant reply focusing on one minor aspect, but ignoring the larger picture; "Being distracted"; well, I didn't see any positive results when you weren't being distracted either... "If you had bothered to ask"? Instead of e.g. reclosing this without even commenting? I would be very happy if you spent your working hours productively, but the results are lacking. Of course, if you consider something that is as extremely buggy as this thing "a fix", then I understand your replies; I can't use them though.
This discussion is not helpful. Please read https://www.mediawiki.org/wiki/Bug_management/Bugzilla_Etiquette This report is far from perfect since Comment 0 since all we have to evaluate is "VisualEditor: Support copy and paste from other VE instances (surfaces)" Now this support is in place. You are saying that it doesn't work in certain circumstances. Are there file bugs opened for the circumstances you can reproduce? Currently we have Bug 33105 - VisualEditor: Preserve rich text formatting when pasting from internal or external sources (tracking) which tracks 6 bug reports. Are the problems you are encountering covered there? I didn't read the whole conversation at the wiki page, but the problems seemed to be related with formatting being lost from copy to paste, which is what Bug 33105 is tracking. If not, please create new bugs for the cases that are missing.
@Quim somewhat true, but we should also not forget that if you have a title like: "support copy and paste from other VE instances", which basically reads as a user story, that you can expect folks to judge the ticket as a user story as well. We say that this is fixed because the basic technical backbone work for it has been done and that the 'content' part of it is separate tracked in it's parent ticket, but that is a very narrow definition of course when the line between user/developer is as thin as it often is on bugzilla. Such differences are bound to create friction.
(In reply to comment #21) > This discussion is not helpful. Please read > > https://www.mediawiki.org/wiki/Bug_management/Bugzilla_Etiquette > > This report is far from perfect since Comment 0 since all we have to evaluate > is > > "VisualEditor: Support copy and paste from other VE instances (surfaces)" > > Now this support is in place. You are saying that it doesn't work in certain > circumstances. Are there file bugs opened for the circumstances you can > reproduce? Currently we have > > Bug 33105 - VisualEditor: Preserve rich text formatting when pasting from > internal or external sources (tracking) > > which tracks 6 bug reports. Are the problems you are encountering covered > there? I didn't read the whole conversation at the wiki page, but the > problems > seemed to be related with formatting being lost from copy to paste, which is > what Bug 33105 is tracking. > > If not, please create new bugs for the cases that are missing. This discussion is not helpful? On the contrary, it has made the position of many devs a lot clearer, and the gap between them and their "customers", for lack of a better word. That it may have violated your Bugzilla Etiquette is the least of my concerns, and that my Bugzilla access may be taken away is your loss, not mine. I am not saying that "it doesn't work in certain circumstances", I'm saying that it doesn't work in nearly all circumstances. Are there file bugs opened for it? Don't know, don't really care. I have done your (devs) job, testing the software, and have reported at length what I encountered in those far from exhaustive tests. Perhaps now you (devs) can do what is apparently my job, and file the bugs? The arrogance of this thread and these statements may escape you, but it is unmistakeable for an outsider. What bugs are coupled at the moment to the mythical bug 33105 ("The main work is done' Priority back to normal")? Bug 37932 is not relevant, 48172 may be related, 48720 is not relevant, 50126 has nothing to do with my reported problems, 51725 doesn't seem to be about what the title describes, 52091 is about copying from read mode (which WhatamIDoing (WMF) claimed was not what this was about)... So no, the many problems I reported are not yet noted, or at least not coupled to 33105. "If not, please create new bugs for the cases that are missing." No, even though you ask nicely, but the treatment by others, the ones that should have found these problems in the first place, doesn't give me any reason to waste my time repeating the errors I reported here once again, where they will be closed at the whim of a dev anyway, sometimes fixed, sometimes not. I hope that someone who should have tested this from the WMF devs or the in-name-only QA team will be a tiny bit ashamed about all that's happened here, and file the bugs themselves. I doubt it though. It's easier to blame the messenger than to look at your own faults.
(In reply to comment #22) > @Quim somewhat true, but we should also not forget that if you have a title > like: "support copy and paste from other VE instances", which basically reads > as a user story, that you can expect folks to judge the ticket as a user > story as well. Yes, I fully agree. This is what I meant in previous post when qualifying this bug report (perhaps too nicely) as far from perfect. We have a title and a one-line comment that doesn't provide any details about the feature expected. It was filed more than a year ago, when VisualEditor was basically a feature developed and used by one small team. The note to remember is that even in those circumstances reports filed must be minimally descriptive in order to set a clear expectation about the requirement to fix it. Anyway, back to the actual problem. Many more bug reports have been added to tracking Bug 33105 (thank you!) which is clearly the report that will define the quality of copy&pasting in VisualEditor.
I did a quick test on mediawiki.org just now using [[mw:VisualEditor:What A]] and [[mw:VisualEditor:What B]]. It seems to mostly work in my browser, though it inserted a non-breaking space before the header. I'll file a separate bug about this. This bug report seems to be resolved/fixed and I'll echo others in suggesting that new bug reports be filed for cases in which copying and pasting misbehaves. Basic support appears to be implemented, however.
(In reply to comment #25) > I did a quick test on mediawiki.org just now using [[mw:VisualEditor:What A]] > and [[mw:VisualEditor:What B]]. It seems to mostly work in my browser, though > it inserted a non-breaking space before the header. I'll file a separate bug > about this. Filed as bug 58563.
