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)

defect

Tracking

()

VERIFIED FIXED

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
QA Contact: petersen → elig
Mike, I wasn't sure who to assign this to. You seemed like the best choice
[QA Assigning to self.]
Assignee: mjudge → akkana
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 :)
Assignee: akkana → buster
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. ***
Blocks: 12902
Target Milestone: M11
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 :-)
Blocks: 13465
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.
Status: NEW → ASSIGNED
Depends on: 2253
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.
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?
Target Milestone: M11 → M12
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.
Blocks: 14356
Whiteboard: [PDT+]
Putting on PDT+ radar
Blocks: 14026
Blocks: 8009
Blocks: 10770, 12658
Priority: P3 → P1
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+] → [PDT+] [by 11/19]
Blocks: 18951
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.
Blocks: 19423
Assignee: buster → radha
Status: ASSIGNED → NEW
reassigning to Radha -- does this unblock you?
Assignee: radha → buster
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]
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
Re-assigning to 12/10.
Depends on: 19428
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
marking fixed.
Blocks: 20870
Status: RESOLVED → REOPENED
Assignee: davidm → hyatt
Status: REOPENED → NEW
Hunted down hyatt who says that this still needs more coding to be considered
resolved.

Thus, re-opening and re-assigning to hyatt.
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
cc'ing brendan
Assignee: hyatt → buster
Everything is in.  Reassigning to buster.
Assignee: buster → don
So this is ready for DOn's team I think.
Status: NEW → RESOLVED
Closed: 25 years ago25 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."
Status: RESOLVED → REOPENED
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
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 Contact: elig → beppe
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"
No longer blocks: 13465
No longer blocks: 4722
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
No longer blocks: 18951
No longer blocks: 20870
You need to log in before you can comment on or make changes to this bug.