Last modified: 2014-04-07 14:07:31 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
Please provide screenshots.
Created attachment 7086 [details] Wiki_prod_2010-02-08_format.pdf attached
Seems related, although opposite behavior of #22398.
(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.
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.
(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.
(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
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.
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.
Solved in r62375.
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
correction on rev # -> r62528
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. ***
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.
Created attachment 7147 [details] Wiki_2010-02-18_SafariEdit.pdf
(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
Fixed in r62682
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.)
(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.
(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?
Created attachment 7162 [details] pasted text from a portion of a web page
(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. ***
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.
