4617 - Copy of text doesn't work in browser only

Status: VERIFIED DUPLICATE of bug 14026

(SeaMonkey :: UI Design, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

I know this is really a browser bug, but Greg asked me to mark the component
Editor so that he could find it more easily.

Copying of text works correctly in editor, but not in browser even though the
code is the same in both places. The xif that is created from the selection
contains all the appropriate header/footer tags, but the selected text that is in
the layout window just doesn't show up. Stepping through the conversion from
selection object to XIF shows that we never find any text nodes to parse!

This should be xp. The fact that it works in editor is very very strange.

Comment 1

[Greg Kostello]

It turns out that the DoCopy message is being sent to the ToolBar frameset and
not the content area of the browser window. You will need to change the code to
send the message to the correct object.
Reassigning to Rod Spears.

Comment 2

[Greg Kostello]

Adding Pinkerton, Dagley and Kostello to the CC field

Comment 3

[rods (gone)]

I think this is a frame set problem. I can do a copy just fine when there isn't
a frame set. (this could be related to the printing bug 4745)

It work in the editor because there isn't a frameset.

Comment 4

[Mike Pinkerton (not reading bugmail)]

Talk to matt about this because he's the one doing the sidebar and frameset
stuff. There are also other bugs filed that read like this one (blah blah
blah...it works when there isn't a frame set...blah blah).

Adding matt to the cc list.

Comment 5

[matt]

The real bug here is that you can
not copy in frames pages.

In the browser once
you are off the initial startup page things
should copy should work as normal.

Comment 6

[troy]

Chris, the bug reports to be a framset problem. However, since it's a "copy"
problem I don't know whether it's you or one of the editor folks doing the copy
work

Comment 7

[Greg Kostello]

I'm not sure exactly how this got assigned to Troy in the first place, but the
issue is simply that the wrong object is getting the message. I tracked down
what was happening and it turns out that the Copy code was being directed to
encode the frameset that contained the toolbar and not the content area. I think
this bug really belongs to whomever is in charge of the Copy feature on the
browser.

Comment 8

[rods (gone)]

I was just debugging it and I disagree with greg conclusion, in the debugger it
is getting the PreShell for the correct IFRAME and doing the print on it. The
IFRAME points to a document that contains a frame set. If the IFRAME points to a
document that does not contain the frame set then it prints ok.

Comment 9

[rods (gone)]

Ok, I am not sure owns this bug. But here is what is going on:

The Browser has a pointer to a document, that is the document of the IFRAME. The
IFRAME was a frameset where each frame has it's own document. The selection
occurs in one of the frameset's frame child's document. When the Copy command is
invoked it uses the IFRAME to get the PreShell, the PresShell (IFRAME) then get
the selection (the selection is pointing at DOMNodes in a completely different
document) the XIF is then created. The copy is blank because the wrong document
is being used to generate the XIF.

The solution is (I think): The selection needs to keep track of what document
and PresShell was used to create it. Then the browser can just go get the
selection's PresShell and document and then do the right thing.

Comment 10

[Greg Kostello]

Mike, this is changed to you. Please talk with Rod if you think his fix is
appropriate.

Comment 11

[mjudge]

This cannot be fixed quickly. This touches on the "focus" issues that the editor
also has to solve.  Tom Pixley has some ideas on this, but we really need to
find the right people to answer this question.  Latering this to M5 and planning
meeting on tuesday.

Comment 12

[mjudge]

this is that dang focus issue comming back again. what to do what to do.  I
think i have another bug listed for m6 that has to do with the selection not
knowing when to draw ect. i am going to leave this bug seperate, but i am going
to M6 it.

Comment 13

[mjudge]

this really should go to xp apps people. i will sit on it till m7 since i am not
messing with the browser chrome for now

Comment 14

[leger]

Setting Component to XPApps

Comment 15

[don]

Let's deal with this in M10 when the focus problems are solved ...

Comment 16

[don]

Focus still doesn't work.  Move to M12 and decide whether we need this for
dogfood.

Comment 17

[don]

Move to M13.

Comment 18

[Kathleen :Brade]

this sounds like 14026 also; can one of these be a duplicate of the other?

Comment 19

[don]

Resolved as duplicate.


*** This bug has been marked as a duplicate of 14026 ***

Comment 20

[sujay]

verified in 12/3 build.