#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