Closed
Bug 21832
Opened 25 years ago
Closed 25 years ago
Browser content frequently cannot be copied
Categories
(SeaMonkey :: UI Design, defect, P3)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
M14
People
(Reporter: elig, Assigned: mikepinkerton)
References
Details
(Whiteboard: [PDT+])
* TITLE/SUMMARY
[DOGFOOD] Browser content frequently cannot be copied
* STEPS TO REPRODUCE
0) Launch Apprunner
1) View a web page, such as:
a. http://slip/projects/marvin/copy-paste/copy-bad-stuff/copy-bad-stuff.html
b. http://slip/projects/marvin/copy-paste/copy-bad-stuff/
2) Select text from either page, and choose "Copy" from the Edit menu.
(for a, I just selected "Checkbox:"; for b, I selected the entire page)
* RESULT
- What happened
The clipboard content will not contain the selected text, but will instead
contain the text that was selected beforehand. Pasting the results of 1b into
Composer will reproducibly crash Seamonkey (Win32 checked; will investigate
further and write a bug separatereport.)
However, on some pages (e.g. www.mozilla.org), the browser _can_ copy text to the
clipboard.
- What was expected
The user should be able to copy text to the clipboard on all pages.
* REGRESSION
- Occurs On
Mac OS & Win32 Apprunner (12.15.99 AM optimized build)
- Doesn't Occur On
Mac OS Communicator 4.7 (RTM)
[Shirirang is using my Linux system right now --- will check on Linux and add to
bug ASAP.]
* CONFIGURATIONS TESTED
- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6
- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.
- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
Reporter | ||
Updated•25 years ago
|
QA Contact: paulmac → elig
Summary: [DOGFOOD] Browser content frequently cannot be copied → [DOGFOOD] Browser content frequently cannot be copied
Reporter | ||
Comment 1•25 years ago
|
||
QA Assigning to self.
I am going to reassign to don since I will not be able to look at this since I am
going on vacation. I have a feeling that this is a selection bug.
Reporter | ||
Comment 3•25 years ago
|
||
[verified also takes place on Linux.]
akanna, can you do a copy from these test pages and do a trace please? We need
more data for PDT..thanks!
Comment 6•25 years ago
|
||
Just a note, seem to be working pretty well on win98 on 12/15 build, I was able
to cut and paste out of browser window, though occasionly it was a bit flaky.
Eli will try to track it down tomorrow.
Comment 8•25 years ago
|
||
another side-effect, or at least related behavior, is that the shortcut (Ctrl+C
on win, Cmd+C on mac, etc.) won't work reliably either. adding myself to cc
list since this affects some of my testing...
Comment 9•25 years ago
|
||
I can't make this fail on Linux with either of the pages Eli references, either
in this morning's release build, or in my debug build updated this afternoon.
It's possible that this might be platform specific. Pinkerton, can you try it
on a Mac? Eli, are you still seeing this? On which platforms?
Updated•25 years ago
|
Assignee: akkana → don
Comment 11•25 years ago
|
||
Handing back to XP Apps team.
Reporter | ||
Comment 12•25 years ago
|
||
[sorry for lack of more prompt follow-up --- got in late from doctor's appt...
following up now.]
Comment 13•25 years ago
|
||
Just tried this on the Mac, after using today's opt comm installer. Worked the
first time (using Cmd-C), failed thereafter. The installed bits are dated 12/14
though.
Reporter | ||
Comment 14•25 years ago
|
||
Yes. Just reproduced it in Akkana's cube on Linux...and now it works fine on my
Mac. Trying to narrow down a test case.
Comment 15•25 years ago
|
||
Steps we used to reproduce it:
mozilla "http://bugzilla.mozilla.org/show_bug.cgi?id=21832"
Scroll down to see the two links; click on one.
Drag the mouse to select some text.
Do Edit->Copy.
Nothing is copied (you don't see the printf that says
->>>>>>>>>>>>>> Write Clipboard to memory
and if you try to paste, nothing is pasted).
I checked the nsDOMWindowController: neither SupportsCommand nor DoCommand is
called with cmd_copy, either from Edit->Copy or from the key binding. The
command controller isn't being notified. Cc'ing saari as the expert on how
commands get routed to these controllers.
Reporter | ||
Comment 16•25 years ago
|
||
I'm throwing my hands up into the air and concluding that I'm not finding a
simplified, reproducible test case. I think it'll be more efficient to hand this
bug over to engineering, and deal with it on a code level.
Good luck. ;)
Comment 17•25 years ago
|
||
Don, I think 21857 may be a dup of this, I assigned that one to mjudge, but he
may not be the correct assigned to.
Updated•25 years ago
|
Assignee: don → hyatt
Comment 18•25 years ago
|
||
(It is very infuriating the way bugzilla throws my comments away when someone
else updates the bug at the same time!)
Mjudge realized what was going on -- this is a dup of the focus problem that
Hyatt is working on. Click in the content area, click in the url bar, then
click back in the content area, and now copy will work -- just like you have to
click in the urlbar, content area, urlbar before xul keybindings will work in
the urlbar.
Reassigning to hyatt.
Comment 19•25 years ago
|
||
*** Bug 21823 has been marked as a duplicate of this bug. ***
Comment 20•25 years ago
|
||
*** Bug 21857 has been marked as a duplicate of this bug. ***
Comment 21•25 years ago
|
||
I'm seeing basically what was originally described:
Launch Mozilla to default page (mozilla.org)
Select some text, let's call it T1, and copy it.
Paste it into Notepad.
go back to Mozilla
Select some other text, T2, and copy.
Go back to Notepad
Paste.
Result: T2 is pasted twice.
Seems to be 100% reproducible.
Comment 22•25 years ago
|
||
Major typo- that last 'T2 should be a 'T1'.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 1/5
Comment 23•25 years ago
|
||
I think this has to do with the fact that when a new Web page loads in a
webshell, it blows away the focus information in the event state manager.
Because we load about:blank and THEN load a Web page, you end up in this bad
state immediately. Only by focusing a legitimate element (e.g., a tree) and
returning to the window will you correct the problem.
Won't be fixed until after break, since i'm going on vacation from the 18th to
the 2nd.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 24•25 years ago
|
||
Fixed.
Reporter | ||
Comment 25•25 years ago
|
||
Umm...I can't tell from Bonsai whether this was checked into the M12 or M13
branch; I still see this using the 1999122011 Win32 M12 build.
Will request addition to Most Frequent Bugs & Release Notes lists.
Reporter | ||
Comment 26•25 years ago
|
||
I don't think I can verify this until 14026 is cleared out.
I'm seeing the same problem (as originally described --- can't reproduce
trudelle's bug), but am unsure if it's a different focus problem yielding similar
symptoms.
Comment 27•25 years ago
|
||
This is still very much a problem on linux -- you still can't copy from the
browser window most of the time, sometimes getting the message
JavaScript Error: TypeError: controller has no properties
and sometimes no output at all -- but now bug 14026 seems to be the main bug
tracking it.
Reporter | ||
Comment 28•25 years ago
|
||
Akkana, do you feel that this bug should be marked as Verified/Fixed if the issue
is being tracked in 14026, or would you prefer that it be re-opened?
Thanks!
Reporter | ||
Comment 29•25 years ago
|
||
Err...actually...I'd like to be anal and just re-open it in the interim. (If
anyone feels otherwise, please feel free to just re-Resolve the bug.)
Reporter | ||
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 31•25 years ago
|
||
Argh. Just use 14026.
*** This bug has been marked as a duplicate of 14026 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Comment 32•25 years ago
|
||
Yes. Marking this Dup Verified. 14026 is marked PDT+/
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 33•25 years ago
|
||
Re-opening, per trudelle's request in 14026 that "Let's confine this bug to the
originally reported problem".
This bug is still occuring on 2.17.00 builds on Mac OS & Win32. (Worked on
Linux.)
(Specifically, following the steps in this bug report, I can't copy the
"Checkbox:" text on copy-bad-stuff.html. I think Akkana said weeks ago that the
other example is generated content, so I didn't check it.)
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Comment 34•25 years ago
|
||
Interesting. I can copy text from the directory listing, and from other page
content, but not 'Checkbox' on the first page cited. Perhaps the problem is
limited to names of HTML Form Controls? (Checkbox is the name of the input field)
Clearing PDT+ for reconsideration, reassigning to pinkerton
Assignee: hyatt → pinkerton
Status: REOPENED → NEW
Whiteboard: [PDT+] 1/5
Target Milestone: M13 → M14
Comment 35•25 years ago
|
||
On linux, I can copy from "Checkbox", but the result is unusable: when I try to
paste I get:
Transferable didn't support data flavor text/unicode (type = 31)
I've been seeing that trying to copy from mail windows, too: I've been
completely unable to copy from a mail message pane, and endico mentioned the
same problem in a comment under another bug report.
Removing dogfood in subject, adding beta1 keyword for consideration. I can help
track this down if it's decided that it's a PDT+ bug.
Keywords: beta1
Summary: [DOGFOOD] Browser content frequently cannot be copied → Browser content frequently cannot be copied
Assignee | ||
Comment 36•25 years ago
|
||
oookie, i'm baffled. no one else has reported linux clipboard problems lately.
hrm...
Status: NEW → ASSIGNED
Updated•25 years ago
|
Assignee: pinkerton → akkana
Status: ASSIGNED → NEW
Comment 37•25 years ago
|
||
Turns out Simon has a fix for the mail copy problems -- see bug 19428.
The problem with copy-bad-stuff.html is due to this line at the beginning of the
file:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
If I remove that line, the content copies correctly. With that line in place,
with some part of the word "Checkbox" selected, the call to the parser/output
sink returns a null string, which causes the message I'm seeing.
The error message is not very helpful (it would be much more useful to see
something like "conversion from text/xif to text/unicode returned a null
string!" which is really what's happening) but the real bug here is mine (at
least to track down further at this point; might also be the parser).
Comment 38•25 years ago
|
||
On second thought, now that we can copy from the mail window, this isn't really
the original issue even though it's the original url. So I filed 28447 to
myself on the doctype issue, and am giving this back to pinkerton (and will mark
fixed, since I think it is).
Assignee: akkana → pinkerton
Comment 39•25 years ago
|
||
Marking fixed since the remaining issues have other bugs filed.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 41•25 years ago
|
||
I'm rubber-stamping this as verified, on the grounds that the issue originally
reported is now covered by a separate bug.
I've also skimmed through the various bugs resolved as duplicate of this bug
(other than Trudelle's comments, which I tried earlier), and can't reproduce them
from quick testing.
If anyone has raised an issue in this bug which you feel hasn't been addressed,
please re-open this bug, or (preferably) split it into a separate bug.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•