12022 - [DOGFOOD] [FEATURE] Need support for cut, copy and paste

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P1)

Description

[Radha on family leave (not reading bugmail)]

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?

Comment 1

[troy]

Mike, I wasn't sure who to assign this to. You seemed like the best choice

Comment 2

[Eli Goldberg]

[QA Assigning to self.]

Comment 3

[mjudge]

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 :)

Comment 4

[Akkana Peck]

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.

Comment 5

[Kathleen :Brade]

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 6

[Kathleen :Brade]

*** Bug 13191 has been marked as a duplicate of this bug. ***

Comment 7

[Chris McAfee]

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 :-)

Comment 8

[buster]

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

[Akkana Peck]

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

[buster]

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

[Akkana Peck]

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.

Comment 12

[Radha on family leave (not reading bugmail)]

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

[buster]

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

[leger]

Putting on PDT+ radar

Comment 15

[buster]

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.

Comment 16

[buster]

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.

Comment 17

[buster]

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.

Comment 18

[rubydoo123]

reassigning to Radha -- does this unblock you?

Comment 19

[don]

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

[hangas]

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.

Comment 21

[rubydoo123]

setting fix by date to 12/10, Steve reset fix by date to 12/3 if you think you
can resolve this - this week

Comment 22

[buster]

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?

Comment 23

[don]

Re-assigning to 12/10.

Comment 24

[davidm]

marking fixed.

Comment 25

[Eli Goldberg]

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

[leger]

Clearing FIXED resolution due to reopen.

Comment 27

[Peter Trudelle]

cc'ing brendan

Comment 28

[David Hyatt]

Everything is in.  Reassigning to buster.

Comment 29

[David Hyatt]

So this is ready for DOn's team I think.

Comment 30

[don]

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

[Eli Goldberg]

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."

Comment 32

[Akkana Peck]

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.

Comment 33

[don]

It's covered by bug #14026 as far as I know.

Comment 34

[Eli Goldberg]

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.

Comment 35

[Eli Goldberg]

QA Assigning to beppe to assign to an appropriate engineer for verification.

Comment 36

[Eli Goldberg]

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

[leger]

sujay, I believe you coudl check to see if this in place on all platforms pretty 
easily.  Please Verify with latest builds.  Thanks!

Comment 38

[sujay]

can't verify until 14026 is fixed and verified....

Comment 39

[sujay]

14026 is fixed and verified....marking this bug verified in 2/21 build.

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c646dd96c46b
[fenix] Import l10n. (https://github.com/mozilla-mobile/fenix/pull/12022)