Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-21903

Copy & paste with chrome insert non break space

    Details

      Description

      I'm unsure if this should be regarded as a bug on eZOE, or if we could implement an enhancement to account for a bug in Chrome and / or tinyMCE stack.

      steps to reproduce
      • Using chrome, in an eZ Publish 5.1 admin portal, edit or create a new article object
      • In the Body field enter some text, select it, copy to clipboard, go to end of line, enter a space, paste, enter another space, paste again, publish
      • View the article (either in front end or back end), inspect the text element.
        . You'll verify that the spaces between the pasted text have been replaced by non breakable spaces "& nbsp ;"

      This could only be reproduced with chrome and seems to be related to this tinyMCE bug report.

      The ill effect of this behavior is that editors won't notice that the XML saved has the special characters until some layout in the front end breaks, due to the non breakable spacing used.

      I've compared the contents stored in MySQL ezcontentobject_attribute using chrome and firefox.
      At a first glance, data_text seems the same.
      But, if you select a different codepage (set names cp1250, for instance) instead of the default and expected utf8, you'll verify that chrome is adding some unexpected character to the content, right where the non breaking spaces show up

        Issue Links

          Activity

          Joaquim Cavalleri (Inactive) created issue -
          Joaquim Cavalleri (Inactive) made changes -
          Field Original Value New Value
          Description I'm unsure if this should be regarded as a bug on eZOE, or if we could implement an enhancement to account for a bug in Chrome and / or tinyMCE stack.

          h5. steps to reproduce
          * Using chrome, in an eZ Publish 5.1 admin portal, edit or create a new article object
          * In the Body field enter some text, select it, copy to clipboard, go to end of line, enter a space, paste, enter another space, paste again, publish
          * View the article (either in front end or back end), inspect the text element.
           . You'll verify that the spaces between the pasted text have been replaced by a non breakable space "*& n b s p ;*"

          This could only be reproduced with chrome and seems to be related to this _tinyMCE_ [bug report|http://www.tinymce.com/develop/bugtracker_view.php?id=4919].

          The ill effect of this behavior is that editors won't notice that the XML saved has the special characters until some layout in the front end breaks, due to the non breakable spacing used.

          I've compared the contents stored in MySQL ezcontentobject_attribute using chrome and firefox.
          At a first glance, data_text seems the same.
          But, if you select a different codepage (set names cp1250, for instance) instead of the default and expected utf8, you'll verify that chrome is adding some unexpected character to the content, right where the non breaking spaces show up
          I'm unsure if this should be regarded as a bug on eZOE, or if we could implement an enhancement to account for a bug in Chrome and / or tinyMCE stack.

          h5. steps to reproduce
          * Using chrome, in an eZ Publish 5.1 admin portal, edit or create a new article object
          * In the Body field enter some text, select it, copy to clipboard, go to end of line, enter a space, paste, enter another space, paste again, publish
          * View the article (either in front end or back end), inspect the text element.
           . You'll verify that the spaces between the pasted text have been replaced by non breakable spaces "_& n b s p ;_"

          This could only be reproduced with chrome and seems to be related to this _tinyMCE_ [bug report|http://www.tinymce.com/develop/bugtracker_view.php?id=4919].

          The ill effect of this behavior is that editors won't notice that the XML saved has the special characters until some layout in the front end breaks, due to the non breakable spacing used.

          I've compared the contents stored in MySQL ezcontentobject_attribute using chrome and firefox.
          At a first glance, data_text seems the same.
          But, if you select a different codepage (set names cp1250, for instance) instead of the default and expected utf8, you'll verify that chrome is adding some unexpected character to the content, right where the non breaking spaces show up
          Joaquim Cavalleri (Inactive) made changes -
          Description I'm unsure if this should be regarded as a bug on eZOE, or if we could implement an enhancement to account for a bug in Chrome and / or tinyMCE stack.

          h5. steps to reproduce
          * Using chrome, in an eZ Publish 5.1 admin portal, edit or create a new article object
          * In the Body field enter some text, select it, copy to clipboard, go to end of line, enter a space, paste, enter another space, paste again, publish
          * View the article (either in front end or back end), inspect the text element.
           . You'll verify that the spaces between the pasted text have been replaced by non breakable spaces "_& n b s p ;_"

          This could only be reproduced with chrome and seems to be related to this _tinyMCE_ [bug report|http://www.tinymce.com/develop/bugtracker_view.php?id=4919].

          The ill effect of this behavior is that editors won't notice that the XML saved has the special characters until some layout in the front end breaks, due to the non breakable spacing used.

          I've compared the contents stored in MySQL ezcontentobject_attribute using chrome and firefox.
          At a first glance, data_text seems the same.
          But, if you select a different codepage (set names cp1250, for instance) instead of the default and expected utf8, you'll verify that chrome is adding some unexpected character to the content, right where the non breaking spaces show up
          I'm unsure if this should be regarded as a bug on eZOE, or if we could implement an enhancement to account for a bug in Chrome and / or tinyMCE stack.

          h5. steps to reproduce
          * Using chrome, in an eZ Publish 5.1 admin portal, edit or create a new article object
          * In the Body field enter some text, select it, copy to clipboard, go to end of line, enter a space, paste, enter another space, paste again, publish
          * View the article (either in front end or back end), inspect the text element.
           . You'll verify that the spaces between the pasted text have been replaced by non breakable spaces "_& nbsp ;_"

          This could only be reproduced with chrome and seems to be related to this _tinyMCE_ [bug report|http://www.tinymce.com/develop/bugtracker_view.php?id=4919].

          The ill effect of this behavior is that editors won't notice that the XML saved has the special characters until some layout in the front end breaks, due to the non breakable spacing used.

          I've compared the contents stored in MySQL ezcontentobject_attribute using chrome and firefox.
          At a first glance, data_text seems the same.
          But, if you select a different codepage (set names cp1250, for instance) instead of the default and expected utf8, you'll verify that chrome is adding some unexpected character to the content, right where the non breaking spaces show up
          Joaquim Cavalleri (Inactive) made changes -
          Status Open [ 1 ] Confirmed [ 10037 ]
          Gunnstein Lye made changes -
          Status Confirmed [ 10037 ] InputQ [ 10001 ]
          Hide
          Pedro Resende (Inactive) added a comment - - edited

          This issue is present on the latest of TinyMCE, you can easily reproduce it http://www.tinymce.com/.
          One possible walkthrough is described here http://blog.room34.com/archives/5075

          Show
          Pedro Resende (Inactive) added a comment - - edited This issue is present on the latest of TinyMCE, you can easily reproduce it http://www.tinymce.com/ . One possible walkthrough is described here http://blog.room34.com/archives/5075
          Damien Pobel (Inactive) made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Assignee Damien Pobel [ damien.pobel@ez.no ]
          Damien Pobel (Inactive) made changes -
          Remaining Estimate 0 minutes [ 0 ]
          Time Spent 4 hours [ 14400 ]
          Worklog Id 42161 [ 42161 ]
          Damien Pobel (Inactive) logged work - 08/Nov/13 5:08 PM - edited
          • Time Spent:
            6 hours
             

            reproduce and trying to fix

          Damien Pobel (Inactive) made changes -
          Time Spent 4 hours [ 14400 ] 6 hours [ 21600 ]
          Worklog Id 42161 [ 42161 ]
          Hide
          Gaetano Giunta (Inactive) added a comment - - edited

          The workaround suggested in http://blog.room34.com/archives/5075 has been implemented, and cursory testing seems successful.
          I'd probably prefer to augment "paste_postprocess" function though rather than add a new function wiping out all NBSPs though

          Show
          Gaetano Giunta (Inactive) added a comment - - edited The workaround suggested in http://blog.room34.com/archives/5075 has been implemented, and cursory testing seems successful. I'd probably prefer to augment "paste_postprocess" function though rather than add a new function wiping out all NBSPs though
          Hide
          Damien Pobel (Inactive) added a comment -

          The workaround is clearly not an acceptable solution as it removes all non break spaces (in all browser). I already tried to implement something in the paste callbacks without luck so far, I'm trying again...

          Show
          Damien Pobel (Inactive) added a comment - The workaround is clearly not an acceptable solution as it removes all non break spaces (in all browser). I already tried to implement something in the paste callbacks without luck so far, I'm trying again...
          Hide
          Damien Pobel (Inactive) added a comment -

          Gaetano: I know I was just mentioning that for others that might come across this bug.

          Joaquim: actually this is a pure frontend side issue because in Chrome, when you hit space at the end of a line, it adds a non break space, if you type something after, TinyMCE transforms it to a normal space but this transformation does not occur when you are pasting something instead of the normal typing. The weird character you are seeing in the database is the UTF8 character for the non break space and it's perfectly normal to have it when the non break space is wanted.

          Yesterday, I've worked on another workaround which is a bit less brutal as it removes only the potentially unwanted non break space when pasting if the user has a webkit browser and if the non break space is the last character of the line. The only problem I see with this patch is that I have no clue if the non break space was added automatically (and it should be removed) or it was added manually by the user and in this case we should keep it.

          Show
          Damien Pobel (Inactive) added a comment - Gaetano: I know I was just mentioning that for others that might come across this bug. Joaquim: actually this is a pure frontend side issue because in Chrome, when you hit space at the end of a line, it adds a non break space, if you type something after, TinyMCE transforms it to a normal space but this transformation does not occur when you are pasting something instead of the normal typing. The weird character you are seeing in the database is the UTF8 character for the non break space and it's perfectly normal to have it when the non break space is wanted. Yesterday, I've worked on another workaround which is a bit less brutal as it removes only the potentially unwanted non break space when pasting if the user has a webkit browser and if the non break space is the last character of the line. The only problem I see with this patch is that I have no clue if the non break space was added automatically (and it should be removed) or it was added manually by the user and in this case we should keep it.
          Damien Pobel (Inactive) made changes -
          Remote Link This issue links to "TinyMCE issue (Web Link)" [ 12916 ]
          Damien Pobel (Inactive) made changes -
          Summary eZOE: Copy & paste with chrome replaces spaces with   Copy & paste with chrome insert non break space
          Damien Pobel (Inactive) made changes -
          Remote Link This issue links to "Pull request (Web Link)" [ 12917 ]
          Hide
          Damien Pobel (Inactive) added a comment -

          PR: https://github.com/ezsystems/ezpublish-legacy/pull/834

          as mentioned in the PR description, this patch is not perfect as with it, OE might remove some user added non breaking space.

          Show
          Damien Pobel (Inactive) added a comment - PR: https://github.com/ezsystems/ezpublish-legacy/pull/834 as mentioned in the PR description, this patch is not perfect as with it, OE might remove some user added non breaking space.
          Damien Pobel (Inactive) logged work - 15/Nov/13 6:58 PM
          • Time Spent:
            6 hours
             

            fix

          Damien Pobel (Inactive) logged work - 18/Nov/13 5:53 PM
          Show
          Damien Pobel (Inactive) added a comment - Fixed in ezpublish-legacy: master: http://github.com/ezsystems/ezpublish-legacy/commit/65268e2957c7484b7022711397409715548e7f74
          Damien Pobel (Inactive) made changes -
          Time Spent 6 hours [ 21600 ] 7 hours [ 25200 ]
          Worklog Id 42438 [ 42438 ]
          Damien Pobel (Inactive) made changes -
          Status Development [ 3 ] Documentation done [ 10011 ]
          Affects Version/s 5.0 [ 10300 ]
          Affects Version/s 5.2 [ 12582 ]
          Component/s Extensions/eZ Online Editor [ 10700 ]
          Fix Version/s 4.7 Maintenance [ 12583 ]
          Fix Version/s 5.0 Maintenance [ 11287 ]
          Fix Version/s 5.1 Maintenance [ 12301 ]
          Fix Version/s 5.2 Maintenance [ 12782 ]
          Damien Pobel (Inactive) made changes -
          Time Spent 7 hours [ 25200 ] 1 day, 5 hours [ 46800 ]
          Worklog Id 42439 [ 42439 ]
          Joao Pingo (Inactive) made changes -
          Status Documentation done [ 10011 ] QA [ 10008 ]
          Assignee Damien Pobel [ damien.pobel@ez.no ] Joao Pingo [ joao.pingo@ez.no ]
          Hide
          Joao Pingo (Inactive) added a comment -

          QA Approved

          Show
          Joao Pingo (Inactive) added a comment - QA Approved
          Joao Pingo (Inactive) made changes -
          Assignee Joao Pingo [ joao.pingo@ez.no ]
          Status QA [ 10008 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Joao Pingo (Inactive) logged work - 19/Nov/13 5:58 PM
          • Time Spent:
            5 hours
             

            Testing and closed

          Joao Pingo (Inactive) made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Joao Pingo (Inactive) made changes -
          Time Spent 1 day, 5 hours [ 46800 ] 2 days, 2 hours [ 64800 ]
          Worklog Id 42471 [ 42471 ]
          Joao Pingo (Inactive) made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Damien Pobel (Inactive) made changes -
          Link This issue relates to EZP-22313 [ EZP-22313 ]
          Damien Pobel (Inactive) made changes -
          Link This issue relates to EZP-23425 [ EZP-23425 ]
          André Rømcke made changes -
          Workflow eZ Engineering Scrumban Workflow [ 59909 ] EZ* Development Workflow [ 84477 ]
          Alex Schuster made changes -
          Workflow EZ* Development Workflow [ 84477 ] EZEE Development Workflow [ 123132 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Confirmed Confirmed
          8m 28s 1 joaquim.cavalleri@ez.no 05/Nov/13 7:02 PM
          Confirmed Confirmed InputQ InputQ
          14h 19m 1 Gunnstein Lye 06/Nov/13 9:21 AM
          InputQ InputQ Development Development
          2d 1h 35m 1 damien.pobel@ez.no 08/Nov/13 10:57 AM
          Development Development Documentation Review done Documentation Review done
          10d 6h 58m 1 damien.pobel@ez.no 18/Nov/13 5:55 PM
          Documentation Review done Documentation Review done QA QA
          17h 32m 1 Joao Pingo (Inactive) 19/Nov/13 11:27 AM
          QA QA Closed Closed
          5h 34m 1 Joao Pingo (Inactive) 19/Nov/13 5:02 PM
          Closed Closed Reopened Reopened
          56m 15s 1 Joao Pingo (Inactive) 19/Nov/13 5:59 PM
          Reopened Reopened Closed Closed
          0s 1 Joao Pingo (Inactive) 19/Nov/13 5:59 PM

            People

            • Assignee:
              Unassigned
              Reporter:
              Joaquim Cavalleri (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 days, 2 hours
                2d 2h