#5664 HIGH Never A: Copying formatted text out of Browse causes weird behavior.

Zarro Boogs per Child bugtracker at laptop.org
Mon Dec 24 05:17:24 EST 2007


#5664: Copying formatted text out of Browse causes weird behavior.
-----------------------------------------------+----------------------------
 Reporter:  legutierr                          |       Owner:  erikos        
     Type:  defect                             |      Status:  new           
 Priority:  high                               |   Milestone:  Never Assigned
Component:  browse-activity                    |     Version:  Build 650     
 Keywords:  Clipboard Journal Browse Breaking  |    Verified:  0             
 Blocking:                                     |   Blockedby:                
-----------------------------------------------+----------------------------
 When selected text is copied using ctrl-c in Browse, the data is
 apparently stored ''incorrectly'' in the clipboard in a different way than
 non-formatted text, inducing strange behavior.  The clipboard object
 created has the following behavior:
   '''1)''' Paste works differently in different locations: in Browse and
 Pippy, plain text seems to be pasted (without visible html tags and
 without formatting).  In Write formatted text is pasted (without  visible
 html tags). [[br]]
   '''2)''' "Open" sub-menu lists Browse, Write and Etoys[[br]]
   '''3)''' If Browse is selected from Open, a "download started" dialog is
 initiated, listing the datastore filename being written to the filesystem.
 (Or, rather, is read from the filesystem and rewritten; either way, two
 identical files are written to the datastore in such event.)[[br]]
   '''4)''' If the just-created datastore file is read directly from the
 filesystem by Browse by explicitly specifying the file path, however, a
 download does not occur, and the copied text is printed surrounded by html
 tags (as in (5) below).[[br]]
   '''5)''' If Write is selected from Open, the text appears surrounded by
 html tags indicating the formatting, but with no formatting visible (even
 if the text is copied from inside a string that is not proximate to those
 tags in the original source), as in (4) above.[[br]]
   '''6)''' If "Add to journal" is selected, a file is added to the
 datastore identical to those written in (1).[[br]]
   '''7)''' In the journal activity GUI, the files created in (1) and (6)
 above are shown not with a text file icon, but a kind of binary file icon.
 The resume button does nothing when pressed for these entries, and the
 resume pull-down menu in the preview page lists no options for the file to
 be opened.[[br]]
   '''8)''' When the "Copy to clipboard" icon is selected on the preview
 page, the object that appears on the clipboard is labeled "unknown', has a
 weird icon, cannot be opened, and cannot be pasted in any activity.
 [[br]]
 Consider as an example copying the bug number from the headline of a page
 such as this one.  When ''pasted'' back into Browse or into Pippy, "5639"
 would appear; when ''opened'' into Write via the clipboard GUI,
 "<h1>5639</h1>" would appear; when ''opened'' into Browse by specifying
 the file path, "<h1>5639</h1>" would also appear; if "cat -A" is called on
 the datastore file created by (1) or (6), the following is printed in the
 terminal:
 {{{
 M-^?M-~<^@h^@1^@>^@5^@6^@3^@9^@<^@/^@h^@1^@>^@
 }}}
 Calling "cat -A ''<datastorefilename>'' >> tmp.txt", and then opening
 tmp.txt in Browse (via explicit file path) prints the following in Browse:
 {{{
 ÿþ<�h�1�>�5�6�3�9�<�/�h�1�>�
 }}}


 This behavior only applies to data copied from formatted text, not from
 non-formatted text.  The two representative examples I would use are (on
 one hand) the bug number in the headline of this page (which acts weirdly
 on the clipboard) and (on the other hand) the words "The browser" on the
 "Page Load Error" page (which acts normally by not being preceeded by
 control characters in the datastore; by not reverting to some binary file-
 type in the journal gui; by not listing Browse as an open option on the
 clipboard; etc.).  It seems that "formatted text" in this context includes
 explicitly formatted text, as well as text formatted by style sheets, but
 I haven't confirmed this because view source is not available in Browse.
 (What I believe that I have observed is that stylesheet-formatted text
 will get the control-characters and strange encoding but not the html
 tags.)  Interestingly enough, the browser engine also seems to treat raw
 ascii files as formatted text when opened, so any copied text has <pre>
 tags wrapped around it, and is preceded the control character header.
 [[BR]][[br]]
 Calling cat -A on a datastore file that originates from a non-formatted
 text copy looks like this:
 {{{
 The browser
 }}}
 The primary relevance of this bug is that formatted Browse text, when
 copied to the Clipboard, breaks Clipboard-Journal interaction.  It is
 obviously wrong behavior, preventing such clipboard data from being
 preserved in the Journal as it should be; normal unformatted text doesn't
 break the clipboard in the same way.  The secondary importance of this bug
 is that it reveals inconsistencies in the way that data is treated between
 and among activites, the clipboard and the journal. For example, shouldn't
 copying from the clipboard into an empty Write document and opening a
 clipboard object into Write produce the same result?  Why does opening the
 clipboard object into Browse via the GUI cause Browse to initiate a
 download, while opening the same data out of the datastore/store/
 directory via the file path does not?  Also, why is formatted text treated
 so differently from unformatted text in terms of how the characters are
 encoded in the datastore files?
 [[br]][[br]]
 It seems to me that some of this behavior is intentional, and some of it
 isn't.  Nevertheless, because the behavior is inconsistent (even where it
 may be intentional), it is likely to confuse users, and may benefit from
 being reevaluated.
 [[br]][[br]]
 I have reproduced this behavior several times on two separate G1G1 X0
 laptops.

-- 
Ticket URL: <http://dev.laptop.org/ticket/5664>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system



More information about the Bugs mailing list