Last modified: 2014-04-07 14:07:31 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 T24428, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22428 - Line breaks in pasted text not picked up when iframe-wrapper is enabled
Line breaks in pasted text not picked up when iframe-wrapper is enabled
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
WikiEditor (Other open bugs)
unspecified
All All
: Low normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 22398 22565 22953 (view as bug list)
Depends on:
Blocks: 36111
  Show dependency treegraph
 
Reported: 2010-02-08 08:49 UTC by Calcey QA
Modified: 2014-04-07 14:07 UTC (History)
11 users (show)

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


Attachments
Wiki_prod_2010-02-08_format.pdf (56.72 KB, application/pdf)
2010-02-09 03:39 UTC, Calcey QA
Details
Wiki_2010-02-18_SafariEdit.pdf (38.10 KB, application/pdf)
2010-02-18 09:23 UTC, Calcey QA
Details
pasted text from a portion of a web page (31.24 KB, image/png)
2010-02-23 16:53 UTC, nkomura@wikimedia.org
Details

Description Calcey QA 2010-02-08 08:49:33 UTC
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>

2) 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
Comment 1 Roan Kattouw 2010-02-08 19:12:03 UTC
Please provide screenshots.
Comment 2 Calcey QA 2010-02-09 03:39:29 UTC
Created attachment 7086 [details]
Wiki_prod_2010-02-08_format.pdf

attached
Comment 3 Trevor Parscal 2010-02-09 23:06:09 UTC
Seems related, although opposite behavior of #22398.
Comment 4 nkomura@wikimedia.org 2010-02-10 00:01:55 UTC
(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>
> 
> 2) 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.
Comment 5 nkomura@wikimedia.org 2010-02-10 00:08:51 UTC
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.
Comment 6 nkomura@wikimedia.org 2010-02-10 00:11:20 UTC
(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>
> > 
> > 2) 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.
Comment 7 Calcey QA 2010-02-10 09:17:34 UTC
(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
> 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.

Executed the given scenarios and updated the result in  Bug 22401
Comment 8 Tisza Gergő 2010-02-11 08:31:05 UTC
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.
Comment 9 Calcey QA 2010-02-12 06:32:53 UTC
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.
Comment 10 Trevor Parscal 2010-02-12 21:36:29 UTC
Solved in r62375.
Comment 11 nkomura@wikimedia.org 2010-02-15 20:17:16 UTC
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
Comment 12 nkomura@wikimedia.org 2010-02-15 20:18:43 UTC
correction on rev # -> r62528
Comment 13 Calcey QA 2010-02-16 06:25:08 UTC
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.
Comment 14 Trevor Parscal 2010-02-16 19:50:44 UTC
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.
Comment 15 Trevor Parscal 2010-02-16 21:28:13 UTC
*** Bug 22398 has been marked as a duplicate of this bug. ***
Comment 16 Roan Kattouw 2010-02-17 16:39:24 UTC
*** Bug 22565 has been marked as a duplicate of this bug. ***
Comment 17 Calcey QA 2010-02-18 05:48:56 UTC
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.
Comment 18 Calcey QA 2010-02-18 09:23:01 UTC
Created attachment 7147 [details]
Wiki_2010-02-18_SafariEdit.pdf
Comment 19 Calcey QA 2010-02-18 09:24:34 UTC
(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
Comment 20 Nimish Gautam 2010-02-19 00:27:52 UTC
Fixed in r62682
Comment 21 nkomura@wikimedia.org 2010-02-23 16:30:40 UTC
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.

2) Copied text from a web page has aggressive line breaks. (screenshot attached)

3) javascript is inserted when a web page is copied and pasted. (select-all and copy paste a Wikipedia page, and paste in the editor.)
Comment 22 Roan Kattouw 2010-02-23 16:46:37 UTC
(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?

> 2) Copied text from a web page has aggressive line breaks. (screenshot
> attached)
> 
You seem to have forgotten the attachment.

> 3) 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.
Comment 23 Roan Kattouw 2010-02-23 16:48:38 UTC
(In reply to comment #22)
> > 2) 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?
Comment 24 nkomura@wikimedia.org 2010-02-23 16:53:23 UTC
Created attachment 7162 [details]
pasted text from a portion of a web page
Comment 25 nkomura@wikimedia.org 2010-02-23 16:59:37 UTC
(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.
Comment 26 Trevor Parscal 2010-02-23 22:44:07 UTC
The bug in comments #24 is fixed as of r62897.
Comment 27 Frederick Grose 2010-08-15 00:39:08 UTC
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|}
Comment 28 Krinkle 2011-04-04 19:53:39 UTC
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.
Comment 29 DieBuche 2011-05-02 19:46:35 UTC
*** Bug 22953 has been marked as a duplicate of this bug. ***
Comment 30 jb.holcroft 2013-01-07 12:20:25 UTC
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
Comment 31 Andre Klapper 2014-04-07 14:07:31 UTC
The unmaintained beta iframe mode was removed from WikiEditor recently in WikiEditor: https://gerrit.wikimedia.org/r/#/c/123649/

Hence closing as WONTFIX.

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


Navigation
Links