Closed Bug 12022 Opened 20 years ago Closed 20 years ago
[DOGFOOD] [FEATURE] Need support for cut, copy and paste
I'm suppose to hook up cut/copy/paste menu items for apprunner. When the user selects something either from the urlbar or from a text form element the OS keyboard shortcuts work. But I think I need these features in presentation shell to hook up the menuuitems. Presentation shell currently has a copy() method. But not anything for cut or paste. What is the plan for selection in the content area?
Assignee: troy → mjudge
Summary: [FEATURE] Need support for cut, copy and paste → [FEATURE] Need support for cut, copy and paste
Mike, I wasn't sure who to assign this to. You seemed like the best choice
[QA Assigning to self.]
i think this is an akkana bug/feature. please tell me akkana if i am wrong. i hate pushing bugs around if they dont actually belong to the people i give them to :)
What Radha is asking for is an API for cut and paste (the items that require an editor since they modify the dom) in the case of ender text widgets. I would assume that this should look like whatever the API was in the old platform-specific text widgets, and perhaps it's already implemented. Steve would be the expert on whether that API was hooked up yet, I would guess.
Component: Layout → HTML Form Controls
Summary: [FEATURE] Need support for cut, copy and paste → [Dogfood] [FEATURE] Need support for cut, copy and paste
on Mac, cut and paste do work with native text widgets so I assume Steve just needs to hook them up. Steve, this sounds like dogfood to me so I'm marking it as such. Change component to HTML Form Controls.
*** Bug 13191 has been marked as a duplicate of this bug. ***
the dupped bug 13191 was cut/paste for gfx text fields, marking this as a dependency for 12902. Apprunner won't leave the milestone untouched, it defaults to "M1", picking M11, sorry. Filed a bug for that :-)
on windows at least, keyboard shortcuts control-x,v,c all work, so you can use the clipboard with text controls, just not from a menu or toolbar. Does this still qualify as dogfood? how are other platforms with these key bindings? researching API now...
The keyboard shortcuts work, but only because they're hardwired in to the editor, which is wrong (platform dependant, people have to use the Windows key bindings since that's what hardwired in); and the menu items don't work at all. Both menu and key-driven cut/copy/paste should be going through XUL and through an API on the embedded text widget.
Here's what happens now. navigator.xul has a menuitem for Edit>Copy that calls BrowserCopy, which calls the appcore's copy method, which calls the pres shell's DoCopy(). If from nsPresShell::DoCopy we could determine what piece of content had focus, then we could get the corresponding frame and ask it if it knows how to handle copy (via some new interface called "nsIClipboardHandler" or something). nsGfxTextControlFrame would support this interface. It could simply forward the DoCopy() request down to the editor embedded within it. And we could add similar methods for Cut and Paste. This is not a general solution for giving scripts the ability to talk to gfx controls. that's discussed in 2253. If we come up with a better general solution there, then what I said above is irrelevant. But if we don't, then I'd goe with a solution similar to the above. Comments?
Yes, your description sounds like exactly how it should work, and I agree that the general solution of scripts talking to gfx controls is a different problem.
Hyatt, Simon, Paul, and I had a meeting about this Tuesday. I'm posting a design note on netscape.public.mozilla.xpfe now titled "Accessing HTML Text Controls from XUL" soon. Please read it and comment to the group. I don't think all the pieces will be in place until M12, so I'm setting the milestone accordingly. However, once the pieces are in place, it should be an easy kill for the browser team to complete the functionality.
Putting on PDT+ radar
cc don Hyatt & Co. got the infrastructure in place for this. So, it should only take me a day to get in my portion. I'll be able to work on this next week, so let's say it'll be in by 11/19. According to Don, that gives his team enough time to do their part of the work.
Whiteboard: [PDT+] [by 11/19] → [PDT+] [waiting on input from hyatt]
Whiteboard: [PDT+] [waiting on input from hyatt] → [PDT+] [partial implementation in hand]
here's my plan on this: I have this implemented for text areas (not single line text controls) I'm going to try like heck to check in what I have tonight if the tree ever goes green. The browser folks can then go to town on enabling ccp, undo, etc. in text areas. Having done this, it should work automatically for single line text controls once I get that done on my side. The script side doesn't know anything about the actual underlying object, so the improvements will be picked up automatically. The way I've tested this is to put a text area in the address book xul (that part obviously won't be checked in!) Paul had already implemented the script support that my code relies on. And lo and behold, it started working just like that: menus are enabled and disabled, menu items cause editing actions, etc. Hyatt, Paul, and Co. did a great job getting the infrastructure in place for this! If any part of this plan doesn't work for you, please let me know right away. I'm doing it this way because I'm leaving on vacation tomorrow night, and I want to minimize the amount of code I land before I leave.
Whiteboard: [PDT+] [partial implementation in hand] → [PDT+] [partial implementation checked in]
ok, I didn't hear any dissenting voices, so what I have so far is now checked in. You can work on the browser ui and test it with <textarea>, but not <input type=text> yet.
reassigning to Radha -- does this unblock you?
David Matiskella (not Radha) checked this out yesterday (Monday) and cannot determine whether buster checked in enough code to allow him to fix bug #14026 because he 1) cannot find a single text block in the prodouct that properly enables or disables menus as comments indicate they should, and 2) editable text fields are currently not working properly for David to evaluate them. I think the best thing to do is wait for buster to return and have him huddle with David to make sure the right thing gets done for enabling cut/copy/paste in editable text fields (esp. the URL bar) and static content areas.
I just tested the html:textarea on the address book window and it is working well. There are some bugs with it, but it is a giant step in the right direction. The code that allows the Edit menu items to enable/disable based on a widget's controller is glued into address book, mail, mail compose, and the browser. This comes for free when using globalOverlay.xul for the Edit menu items. The browser window is not functioning at this time, I think that it may be an iframe focus problem. Saari is working on a number of iframe focus bugs, and this may be the result of one of those bugs. I would like to try this again after saari has landed some of the iframe focus bug fixes.
Whiteboard: [PDT+] [partial implementation checked in] → [PDT+] [by 12/10] [partial implementation checked in]
setting fix by date to 12/10, Steve reset fix by date to 12/3 if you think you can resolve this - this week
Assignee: buster → don
Component: HTML Form Controls → XPApps
Whiteboard: [PDT+] [by 12/10] [partial implementation checked in] → [PDT+] [by 12/10]
Assignee: don → davidm
Summary: [Dogfood] [FEATURE] Need support for cut, copy and paste → [DOGFOOD] [FEATURE] Need support for cut, copy and paste
Whiteboard: [PDT+] [by 12/10] → [PDT+] 12/10 completion
Re-assigning to 12/10.
Hunted down hyatt who says that this still needs more coding to be considered resolved. Thus, re-opening and re-assigning to hyatt.
Clearing FIXED resolution due to reopen.
Everything is in. Reassigning to buster.
So this is ready for DOn's team I think.
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Someone want to explain to me why this has been re-opened? Buster has done all the work already. We have other bugs for the remaining tasks. Correct me if I'm wrong ...
It's been re-opened for exactly the reasons that I said when I re-opened it. ;) "hyatt [...] says that this still needs more coding to be considered resolved."
Reopening because in the browser window in today's build, I still see copy disabled when I have text selected, either in the content area or in the urlbar. I thought the point of this bug was that people want to be able to copy from the browser window ... if that's covered by a different bug now, go ahead and close this, citing the other bug.
It's covered by bug #14026 as far as I know.
Is there anyone who would like to take ownership of verifying this? I don't believe it can be verified on a black box level.
QA Assigning to beppe to assign to an appropriate engineer for verification.
This bug is complicated and messy --- I've written up a new bug for a specific case of Browser copy/paste not working on some pages: 21832, "[DOGFOOD] Browser content frequently cannot be copied"
sujay, I believe you coudl check to see if this in place on all platforms pretty easily. Please Verify with latest builds. Thanks!
Component: XPApps → Editor
QA Contact: beppe → sujay
can't verify until 14026 is fixed and verified....
Whiteboard: [PDT+] 12/10 completion → [PDT+] 1/26 status: can't verify until 14026 is fixed and verified....
Whiteboard: [PDT+] 1/26 status: can't verify until 14026 is fixed and verified.... → [PDT+] 1/26 status: can't verify until 14026 is verified+fixed
14026 is fixed and verified....marking this bug verified in 2/21 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.