Closed
Bug 12022
Opened 26 years ago
Closed 25 years ago
[DOGFOOD] [FEATURE] Need support for cut, copy and paste
Categories
(Core :: DOM: Editor, defect, P1)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: radha, Assigned: don)
References
Details
(Whiteboard: [PDT+] 1/26 status: can't verify until 14026 is verified+fixed)
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
Updated•26 years ago
|
QA Contact: petersen → elig
Mike, I wasn't sure who to assign this to. You seemed like the best choice
Comment 2•26 years ago
|
||
[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 :)
Updated•26 years ago
|
Assignee: akkana → buster
Comment 4•26 years ago
|
||
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.
Updated•26 years ago
|
Component: Layout → HTML Form Controls
Summary: [FEATURE] Need support for cut, copy and paste → [Dogfood] [FEATURE] Need support for cut, copy and paste
Comment 5•26 years ago
|
||
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.
Comment 7•26 years ago
|
||
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...
Comment 9•26 years ago
|
||
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.
Comment 10•26 years ago
|
||
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?
Comment 11•26 years ago
|
||
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.
Reporter | ||
Comment 12•26 years ago
|
||
This is exactly what I wanted. But in browser, cut and paste operations are allowed only for the urlbar or any form text elements. The urlbar does not have a presshell. There s'd be a way either from javascript or thro' C++ to talk directly to the text widget from the BrowserAppCore(now BrowserInstance) and ask it to do the CCP operation Also, unlike editor where C/C/P menu options can be valid all the time, the browser enables the Cut/Paste operations only if the focus and the recent selection happened in the urlbar or in a form text element. For this the browser needs to know whenever anything in a text element is selected. This is what David hyatt and I asked you about yesterday and you agreed to look in to. Do you want me to file a separate for that?
Comment 13•26 years ago
|
||
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.
Comment 14•25 years ago
|
||
Putting on PDT+ radar
Updated•25 years ago
|
Updated•25 years ago
|
Priority: P3 → P1
Comment 15•25 years ago
|
||
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.
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] [by 11/19]
Updated•25 years ago
|
Whiteboard: [PDT+] [by 11/19] → [PDT+] [waiting on input from hyatt]
Whiteboard: [PDT+] [waiting on input from hyatt] → [PDT+] [partial implementation in hand]
Comment 16•25 years ago
|
||
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]
Comment 17•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: buster → radha
Status: ASSIGNED → NEW
Comment 18•25 years ago
|
||
reassigning to Radha -- does this unblock you?
Assignee | ||
Comment 19•25 years ago
|
||
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.
Comment 20•25 years ago
|
||
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.
Updated•25 years ago
|
Whiteboard: [PDT+] [partial implementation checked in] → [PDT+] [by 12/10] [partial implementation checked in]
Comment 21•25 years ago
|
||
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]
Comment 22•25 years ago
|
||
Here's what we're going to do. 1) bug 2253 is the editor/layout portion of this problem. I have a fix in hand for that, and will check it in as soon as I can get it polished and code reviewed. I'm taking the liberty of marking it PDT+, since it's a prerequisite to this PDT+ bug. Jar, ok? 2)I am reassigning this bug to gramps. He should get someone from his team (david or radha) to work with paul h. to enable the controllers stuff from browser javascript the same way paul has already done for address book. The browser team can start today and test with <textarea>. When 2253 is marked fixed, they can also work with text input controls. 3) Once the browser team has hooked up the controllers stuff, and it talks to text controls, this bug should be closed. This bug is about building the infrastructure, and at that point it'll be built. Any residual bugs about this menu item doesn't enable/disable appropriately, or that menu item doesn't work as expected, should be filed separately in a new bug. 'k?
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
Assignee | ||
Comment 23•25 years ago
|
||
Re-assigning to 12/10.
Comment 24•25 years ago
|
||
marking fixed.
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Updated•25 years ago
|
Assignee: davidm → hyatt
Status: REOPENED → NEW
Comment 25•25 years ago
|
||
Hunted down hyatt who says that this still needs more coding to be considered resolved. Thus, re-opening and re-assigning to hyatt.
Comment 26•25 years ago
|
||
Clearing FIXED resolution due to reopen.
Comment 27•25 years ago
|
||
cc'ing brendan
Updated•25 years ago
|
Assignee: hyatt → buster
Comment 28•25 years ago
|
||
Everything is in. Reassigning to buster.
Updated•25 years ago
|
Assignee: buster → don
Comment 29•25 years ago
|
||
So this is ready for DOn's team I think.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 30•25 years ago
|
||
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 ...
Comment 31•25 years ago
|
||
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."
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 32•25 years ago
|
||
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.
Assignee | ||
Comment 33•25 years ago
|
||
It's covered by bug #14026 as far as I know.
Comment 34•25 years ago
|
||
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.
Updated•25 years ago
|
QA Contact: elig → beppe
Comment 35•25 years ago
|
||
QA Assigning to beppe to assign to an appropriate engineer for verification.
Comment 36•25 years ago
|
||
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"
Comment 37•25 years ago
|
||
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
Comment 38•25 years ago
|
||
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
Comment 39•25 years ago
|
||
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.
Description
•