Closed Bug 21832 Opened 25 years ago Closed 25 years ago

Browser content frequently cannot be copied

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

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).
QA Contact: paulmac → elig
Summary: [DOGFOOD] Browser content frequently cannot be copied → [DOGFOOD] Browser content frequently cannot be copied
QA Assigning to self.
Assignee: davidm → don
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.
[verified also takes place on Linux.]
Assignee: don → mcafee
Target Milestone: M13
Chris, I need you to take over CCP from David.  S'allright?
Assignee: mcafee → akkana
akanna, can you do a copy from these test pages and do a trace please?  We need
more data for PDT..thanks!
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.
What happens when you choose "Copy"...not cut, not paste?
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...
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?
PDT+
Whiteboard: [PDT+]
Assignee: akkana → don
Handing back to XP Apps team.
[sorry for lack of more prompt follow-up --- got in late from doctor's appt...

following up now.]
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.
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.
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.
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. ;)
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.
Assignee: don → hyatt
(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.
*** Bug 21823 has been marked as a duplicate of this bug. ***
*** Bug 21857 has been marked as a duplicate of this bug. ***
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.
Major typo- that last 'T2 should be a 'T1'.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 1/5
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed.
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.
Depends on: 14026
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.
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.

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!

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.)

doh.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Yes.  Marking this Dup Verified.  14026 is marked PDT+/
Status: RESOLVED → VERIFIED
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 → ---
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
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
oookie, i'm baffled. no one else has reported linux clipboard problems lately. 
hrm...
Status: NEW → ASSIGNED
Assignee: pinkerton → akkana
Status: ASSIGNED → NEW
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).
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
Marking fixed since the remaining issues have other bugs filed.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Putting on the PDT+ radar for beta 1.
Whiteboard: [PDT+]
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
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.