Page MenuHomePhabricator

Line breaks in pasted text not picked up when iframe-wrapper is enabled
Closed, DeclinedPublic

Description

Author: wikibugs

Description:
Reporting against Babaco Release :

Steps to Reproduce ::

  1. Paste the following in an editor

Suppose we want to define <code>int main()</code>:

<source lang=cpp>#include <iostream>
int main ( int argc, char **argv ) {
std::cout << "Hello World!";
return 0;
}</source>

  1. Click on preview

<<Syntax not highlighted as it suppose to>>

Expected Outcome::
All browsers should function the same

Test Environment::
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.78 Safari/532.5


Version: unspecified
Severity: normal

Details

Reference
bz22428

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:53 PM
bzimport added a project: WikiEditor.
bzimport set Reference to bz22428.
bzimport added a subscriber: Unknown Object (MLST).

wikibugs wrote:

Wiki_prod_2010-02-08_format.pdf

attached

Attached:

Seems related, although opposite behavior of #22398.

nkomura wrote:

(In reply to comment #0)

Reporting against Babaco Release :

Steps to Reproduce ::

  1. Paste the following in an editor

Suppose we want to define <code>int main()</code>:

<source lang=cpp>#include <iostream>
int main ( int argc, char **argv ) {
std::cout << "Hello World!";
return 0;
}</source>

  1. Click on preview

<<Syntax not highlighted as it suppose to>>

Expected Outcome::
All browsers should function the same

We are not applying the syntax highlighting with this release. We are trying to remove preserved formatting which was not intended behavior.

nkomura wrote:

Calcey QA Team,
Please also apply test cases such as as follows:

  1. Paste a couple of paragraphs with various line breaks from a word processing document
  2. Paste a sample text from a wiki (MediaWiki project) and preview

Please confirm if the reported are only present for Safari 4 and Chrome 4.

nkomura wrote:

(In reply to comment #4)

(In reply to comment #0)

Reporting against Babaco Release :

Steps to Reproduce ::

  1. Paste the following in an editor

Suppose we want to define <code>int main()</code>:

<source lang=cpp>#include <iostream>
int main ( int argc, char **argv ) {
std::cout << "Hello World!";
return 0;
}</source>

  1. Click on preview

<<Syntax not highlighted as it suppose to>>

Expected Outcome::
All browsers should function the same

We are not applying the syntax highlighting with this release. We are trying
to remove preserved formatting which was not intended behavior.

Please ignore my comment above. Yes, the formatting (Syntax highlighting for this case) should be respected.

wikibugs wrote:

(In reply to comment #5)

Calcey QA Team,
Please also apply test cases such as as follows:

  1. Paste a couple of paragraphs with various line breaks from a word processing

document

  1. Paste a sample text from a wiki (MediaWiki project) and preview

Please confirm if the reported are only present for Safari 4 and Chrome 4.

Executed the given scenarios and updated the result in Bug 22401

I tried the test in the bug description on huwiki/FF 3.5/WinXP (after a cache refresh), and it removes all line breaks upon paste; the whole <source> block ends up in a single line. This is new behavior, it didn't happen a few days ago; the first line break was often removed, though (whether the text was pasted or not), so the empty line between a comment and a reply disappeared.

wikibugs wrote:

Test link :http://prototype.wikimedia.org/deployment-en/
Version : r62243

From Word document
Safari 4 and Chrome 4 removes all the line breaks and add the text in one line.

From wiki document
Copy text from wiki document and past n another wiki editor open on Safari 4 / Chrome 4 browser : same results

Edit a wiki document, copy the content and paste in another wiki editor open on Safari 4 / Chrome 4 browser : same results.

nkomura wrote:

The linebreaks are removed using Chrome 5 on Ubuntu 9.04 as of Feb 15, 8pm UTC.
http://prototype.wikimedia.org/deployment-en/Main_Page

r62529

nkomura wrote:

correction on rev # -> r62528

wikibugs wrote:

Tested link: http://prototype.wikimedia.org/deployment-en/
Version : r62529

From Word document
Safari 4 and Chrome 4 removes all the line breaks and add the text in one line.

From wiki document
Copy text from wiki document and past in another wiki editor open on Safari 4 /
Chrome 4 browser : same results

Edit a wiki document, copy the content and paste in another wiki editor open on
Safari 4 / Chrome 4 browser : same results.

Therefore conclude as bug is not fixed.

Because these browsers enclose copied HTML in a span with class "Apple-style-span", our algorithm for breaking down the HTML was failing. r62589 adds an unwrapping procedure that solves this.

  • Bug 22398 has been marked as a duplicate of this bug. ***
  • Bug 22565 has been marked as a duplicate of this bug. ***

wikibugs wrote:

Tested Link: http://prototype.wikimedia.org/en.wikipedia.org/Main_Page
Tested Version : r62665

From Word document
Safari 4 and Chrome 4 removes all the line breaks and add the text in one line.

From wiki document
Copy text from wiki document and past in another wiki editor open on Safari 4 /
Chrome 4 browser : same results

Edit a wiki document, copy the content and paste in another wiki editor open on
Safari 4 / Chrome 4 browser : same results.

Therefore conclude as bug is not fixed.

wikibugs wrote:

Wiki_2010-02-18_SafariEdit.pdf

Attached:

wikibugs wrote:

(In reply to comment #18)

Created an attachment (id=7147) [details]
Wiki_2010-02-18_SafariEdit.pdf

In addition to the scenario mentioned in Comment 17, sometimes the attachment id 7147 describe also happen only in Safari 4

nkomura wrote:

I still see the following two conditions on the deployment.

  1. line breaks are removed when a set of paragraphs are pasted in to the editor.
  1. Copied text from a web page has aggressive line breaks. (screenshot attached)
  1. javascript is inserted when a web page is copied and pasted. (select-all and copy paste a Wikipedia page, and paste in the editor.)

(In reply to comment #21)

I still see the following two conditions on the deployment.

  1. line breaks are removed when a set of paragraphs are pasted in to the

editor.

Pasted from where? A web page, editor, the wikiEditor itself?

  1. Copied text from a web page has aggressive line breaks. (screenshot

attached)

You seem to have forgotten the attachment.

  1. javascript is inserted when a web page is copied and pasted. (select-all and

copy paste a Wikipedia page, and paste in the editor.)

This should be easily fixable by killing <script> tags in the pasted text.

(In reply to comment #22)

  1. Copied text from a web page has aggressive line breaks. (screenshot

attached)

You seem to have forgotten the attachment.

Looks like bug 22554 comment #2 has the right attachment instead, is this correct?

nkomura wrote:

pasted text from a portion of a web page

Attached:

still_seeing_linebreaks.png (506×719 px, 31 KB)

nkomura wrote:

(In reply to comment #22)

(In reply to comment #21)

I still see the following two conditions on the deployment.

  1. line breaks are removed when a set of paragraphs are pasted in to the

editor.

Pasted from where? A web page, editor, the wikiEditor itself?

From an external editor such as Open Office Word Processor.

The bug in comments #24 is fixed as of r62897.

Confirmed the faulty behavior in r71084 with only the 'Enable enhanced editing toolbar' option selected in the 'Experimental features' of the 'Editing' preferences.

Confirmed on Windows Vista32 with Firefox 3.6.8
and Google Chrome 6.0.490.1 dev.

Test case:
{|

-
row1
-
row2
}

entered as simple text from Notepad or the wikitext area of a page when the 'Enhanced editing toolbar' option was not enabled.

Internet Explorer 8.0.6001.18943 did NOT show faulty behavior.

If the wikitext is copied (Ctrl-C) from the IE8 page and pasted (Ctrl-V) to the Firefox wikitext edit area, two lines appear:
WikiEditor

{||-| row1|-| row2|}

If pasted to the Google Chrome wikitext edit area, only the collapsed text appears:
{||-| row1|-| row2|}

Lowering priority and moving to Extension:WikiEditor.

This functionality only appears if the site admin enables one of the experimental modules that triggers an iframe-wrapper, which has these line-break bugs.

By default the iframe-wrapper is not triggered on in-install, neither on Wikipedia.

*** Bug 22953 has been marked as a duplicate of this bug. ***

jb.holcroft wrote:

In fact, iframe-wrapper is enable by default.
Administrator usally take default options from Mediawiki.org website and the default option is $wgDefaultUserOptions['usenavigabletoc'] = 1;

I submitted a change proposal to the extension page :

https://www.mediawiki.org/w/index.php?title=Extension:WikiEditor&oldid=600994&diff=cur

The unmaintained beta iframe mode was removed from WikiEditor recently in WikiEditor: https://gerrit.wikimedia.org/r/#/c/123649/

Hence closing as WONTFIX.