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.

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.

Adding Pinkerton, Dagley and Kostello to the CC field

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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

Setting Component to XPApps

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

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

Move to M13.

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

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

verified in 12/3 build.