2253 - Need a way to talk to GFX widgets from JavaScript, for menu updating etc.

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[Simon Fraser [no longer active]]

On Windows, you can copy and paste in the text widget (e.g. URL field in
viewer). This does not work on Mac. This is a PITA, because it makes going
to test URL pages very laborious.

Comment 1

[Steve Dagley]

Handing off to pierre (core widget functionality)

Comment 2

[Pierre Saslawsky]

Reassigned to Pink who is working on text widgets.
One of my posting on the newsgroup today contains some info about how to fix this
bug.

Comment 3

[Pierre Saslawsky]

I've done the Paste: you can add Cut and Copy.

Comment 4

[Mike Pinkerton (not reading bugmail)]

Cut and Copy done for both text widget and text area widget. Marking fixed.

Comment 5

[Eli Goldberg]

[pinged pinkerton to find out what 'text area' widget refers to.]

Comment 6

[Pierre Saslawsky]

That's Windows terminology: the 'text' widget is a single line text edit field,
the 'text area' is a multi-line text field usually with scrollbars.

The text widget can actually span over several lines if the field height is
larger than twice the font height, as in the URL field of Viewer.

Comment 7

[Eli Goldberg]

I'm going to re-open this bug, but purely as a formality; please feel free to
mark it as Verified/Fixed unless you think that this is worth fixing in a test
application.

TEXT FIELD:
	Works fine (cut & copy register in the clipboard, and paste works for text
in the clip board)

	...however, there's one small bug in "Cut", in which the character
immediately following the text selection will both be cut from the URL field (and
FWIW not placed into the clipboard, either.)

	To reproduce, type "http://bugzilla.mozilla.org", select "mozilla.", and
choose "Cut". The clipboard will now contain "mozilla." and the URL field will
contain "http://bugzilla.rg".

	Note that this also occurs for text outside of the URL text field (i.e. if
you type the URL into the Netscape Search text field, and do the cut.)

	(I'll check the textarea tag <thanks, Pierre>, and add comments here.)

Comment 8

[Eli Goldberg]

...Unfortunately, TEXTAREA doesn't really work right now, so I can't really
verify it. ;(

See ya.

Comment 9

[Pierre Saslawsky]

I confirm that textArea doesn't work. I wanted to have a quick look at it,
although the code will be replaced later by some XP magic, because it may
generate drawing problems in some pages.

Comment 10

[leger]

Clearing Fixed resolution

Comment 11

[leger]

Inserting Milestone info.

Comment 12

[leger]

Setting all current Open/Normal to M4.

Comment 13

[Steve Dagley]

Cut & paste work in the URL field now so apparently somebody fixed this but
didn't close the bug.

Comment 14

[Eli Goldberg]

Copying text crashes 2.18.99 build. (irregardless of whether in URL text field,
or just part of the document.)

Today's Mac build is too broken to try to verify against; will re-open if this
bug is still taking place on the first set of builds that are sufficiently usable
to test.

Comment 15

[Eli Goldberg]

Copying text on 2.23.99 Mac Viewer build results in Viewer immediately quitting;
no error message provided. This doesn't occur using the Win32 or Linux builds.

Thus, re-opening as a formality.

Comment 16

[Peter Trudelle]

What is the current state of this, and why would xptoolkit need to spend time
maintaining another group's test app? If it is broken in the product
(AppRunner), report it there.

Comment 17

[Pierre Saslawsky]

It was broken in AppRunner too but I fixed it anyway.

Comment 18

[Eli Goldberg]

Cut, Copy & Paste all don't work at all in AppRunner on Mac (3.9.99 build checked). Deferring until this is addressed in order to verify this bug.

Comment 19

[Eli Goldberg]

[Cut/Copy/Paste still nonfunctional in 3.15.99 builds.]

Comment 20

[Eli Goldberg]

Per bug #3642, cut, copy & paste now work.

Mondo verification to follow on this bug shortly.

Comment 21

[Eli Goldberg]

Bug 3642 lies. Deferring (again) on verification until the functionality is
functioning.

Comment 22

[Eli Goldberg]

Aha. This bug 4147 is actually the active bug for tracking the issue in 3642.

Comment 23

[Eli Goldberg]

Re-opening and reassigning to Greg Kostello to either close as no longer relevant
(bug was specific to Viewer), or wave his magic wand in some other fashion.

Thanks.

Comment 24

[Pierre Saslawsky]

Originally, this bug was specific to Viewer because AppRunner did not exist yet.
Since then, it's been fixed in Viewer and it still doesn't work in AppRunner.

Removing the current resolution of Fixed.

Comment 25

[Greg Kostello]

Until Ender replaces the native text widget, this bug is not relevant to the
work being done by the Ender team. Reassigning owner back to the component
owner.

Comment 26

[karnaze (gone)]

Pierre, back to you, since it is MAC specific.

Comment 27

[Pierre Saslawsky]

Moving to M15 all the bugs that have a dependancy on GFX widgets and/or Ender.

Comment 28

[leger]

Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired
shortly.

Comment 29

[Pierre Saslawsky]

Copy and Paste are now implemented in AppRunner but there is still a problem: it
works if you use the keyboard shortcuts (cmd-X, cmd-C) but it doesn't work if you
use the Edit menu. Reassigning to saari since it is a menu problem.

Comment 30

[Chris McAfee]

resummarizing.

Comment 31

[saari (gone)]

I really doubt this is a menu bug.

Comment 32

[Simon Fraser [no longer active]]

The deal here is that we don't yet have a way to talk to GFX text widgets from

JavaScript, so Cut, Copy and Paste are not wired up yet.

Comment 33

[saari (gone)]

So who should this bug be assigned to?

Comment 34

[Simon Fraser [no longer active]]

This is some architecture work that needs to be done by someone in toolkit (or
perhaps apps). Redoing summary, reassigning to trudelle.

Comment 35

[Simon Fraser [no longer active]]

This is some architecture work that needs to be done by someone in toolkit (or

perhaps apps). Redoing summary, reassigning to trudelle.

Comment 36

[Simon Fraser [no longer active]]

This is some architecture work that needs to be done by someone in toolkit (or

perhaps apps). Redoing summary, reassigning to trudelle.

Comment 37

[Simon Fraser [no longer active]]

M15 seems awfully late to have this in. We need this for reasonalble GFX widget
handling, which is coming online any day now.

Comment 38

[buster]

changed platform/os to all.  text controls are XP now, so there should be some
XP way to make this work.
Cut(), Copy(), and Paste() are available on the editor via nsIEditor.
nsGfxTextControlFrame knows how to get to nsIEditor, so it's a matter of the
menu telling the text control to do the CCP action.  How do menus communicate
with frames today:  by direct API calls, by sending DOM events, some other
mechanism?

Comment 39

[Radha on family leave (not reading bugmail)]

I need to get this to work for browser too. I don't understand why the browser
s'd go to nsIEditor to get CCP working.  I have plans to get to the text widget
thro' DOM events. However, today, the text widget does not provide support for
"select" events or "Mouse drag events" so that the browser can listen to those
and figure where the current selection is. I need to know this in order to
decide whether I have to enable just the 'copy' menu item (for selection in the
content area) or enable all the CCP menu items (for urlbar, any form text
elements). Is there a way to get notified on these events in the gfx widgets?

Comment 40

[David Hyatt]

The command dispatcher/focus tracker mechanism is ready to handle this.  You
just need to make sure you've hooked up an nsIController to the text content
node.  The sticky part is how we do this nodal attachment... since you're an
HTML element, we can't legally attach it to the node.

All XUL elements have a controller property, which allows you to attach some
kind of handler to the element, but the HTML text node does not.

Comment 41

[Simon Fraser [no longer active]]

you're teasing us hyatt! So what is a workable solution?

Comment 42

[David Hyatt]

We need to decide how to associate the controller objects with HTML text
elements.  It may be the case that we need to instantiate them behind the scenes
when the frame gets made and add them to some big table in the chrome document.

If we were allowed to make an nsIDOMNSHTMLTextAreaElement and just hang an
nsIController off of it, we'd be all good.  Then you could behave just like XUL.
Vidur would probably be the one to grant or deny such a request.

Comment 43

[Peter Trudelle]

who should this be assigned to?

Comment 44

[David Hyatt]

I would reassign this to buster, since it's really an issue with GFX text
widgets.  I'm happy to work with the editor team to figure out some solution so
that they can interface with our command dispatcher/focus tracker.

Comment 45

[buster]

I'll take it, and work with hyatt.  I'll try hard to get it in by M11, but
there's a good chance it'll slip to M12, so I'm marking M12 as the target
milestone.

Comment 46

[don]

Added dependency to Radha's URL bar cut/copy/paste feature, bug #4722, for beta.

Comment 47

[Simon Fraser [no longer active]]

I was thinking that this mechanism is needed not only for GFX text widgets, but
other widgets too, which was why I didn't try to keep it in the editor group
initially. Is this true? Is there info on other GFX widgets that we might need to
access from JS, through a similar mechanism? I'm thinking of selection in lists
and stuff like that.

Comment 48

[buster]

hyatt said that I shouldn't work on this until the focus work is further along.
assigning back to hyatt, who will assign it back to me when I can do my part.

Comment 49

[David Hyatt]

controller stuff is all ready for ya. saari is ironing out kinks in focus
still.

Comment 50

[rubydoo123]

moving this out to M14 -- code cleanup

Comment 51

[buster]

no, this is not code cleanup.  This is enabling core technology to allow the
browser to link menu items and other commands to text controls.  For example,
without this you couldn't select text in a text control and use the "copy" or
"undo" menu items.
I think this should stay targeted for M12 or M13 at the latest.
Remove [Code cleanup] and retargeting for M12.

Comment 52

[rubydoo123]

ok, then we need to make this a DOGFOOD candidate -- adding dogfood to summary

Comment 53

[buster]

I don't think this work is required for dogfood, because there is a workaround:
use the keyboard bindings.  control-c for copy, control-v for paste, control-z
for undo, etc.  The problem with the workaround is that it isn't
easily discoverable.  So this is certainly a beta stopper, but I don't think
it's a dogfood stopper.

Comment 54

[rubydoo123]

ok, then I'll mark the thing BETA -- if it's beta then it is off the M12 radar
and gets pushed out to M13 or later - hence the M14 milestone setting that I did
this morning. So -- if this is dogfood it stays in M12. If this is a beta
critical blocker, it goes to M13. If this is a beta necessity but can wait till
absolute must haves are in, then it goes to M14. -- your choice.

Comment 55

[buster]

based on beth's criteria, I think this should go in M13.

Comment 56

[rubydoo123]

removing DOGFOOD, putting in BETA BLOCKER, Steve already set it to 13.

Comment 57

[buster]

aren't beta blockers about cholesterol, not software?

marked PDT+ because fixing this is required to fix PDT+ bug 12022.  Moving to
M12.  Fix in hand, waiting for a little spit and polish, then some reviewers.

Comment 58

[rubydoo123]

linking to 12658, composer pdt+ bug tracking

Comment 59

[buster]

fixed.  you can now talk to textareas and single line text inputs via the xul
controllers mechanism.  there are still problems (see bug 20470 and 20471)

Comment 60

[Eli Goldberg]

QA Assigning to beppe; per sfraser, this is a developer-level bug, and should be
confirmed by a developer.

(He mentioned that davidm or law may have been trying to use this functionality
and might know if it's fixed correctly.)

Comment 61

[buster]

dev level fix, verifying.  At a user level, it works in address book, where paul
has already hooked up the plumbing that uses this.