Closed
Bug 2253
Opened 26 years ago
Closed 25 years ago
Need a way to talk to GFX widgets from JavaScript, for menu updating etc.
Categories
(Core :: Layout: Form Controls, defect, P1)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: sfraser_bugs, Assigned: buster)
References
Details
(Whiteboard: [PDT+] [by 12/3])
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.
Updated•26 years ago
|
Assignee: sdagley → pierre
Comment 1•26 years ago
|
||
Handing off to pierre (core widget functionality)
Updated•26 years ago
|
Assignee: pierre → pinkerton
Comment 2•26 years ago
|
||
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•26 years ago
|
||
I've done the Paste: you can add Cut and Copy.
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 4•26 years ago
|
||
Cut and Copy done for both text widget and text area widget. Marking fixed.
Comment 5•26 years ago
|
||
[pinged pinkerton to find out what 'text area' widget refers to.]
Comment 6•26 years ago
|
||
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.
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Comment 7•26 years ago
|
||
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•26 years ago
|
||
...Unfortunately, TEXTAREA doesn't really work right now, so I can't really
verify it. ;(
See ya.
Comment 9•26 years ago
|
||
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•26 years ago
|
||
Clearing Fixed resolution
Comment 11•26 years ago
|
||
Inserting Milestone info.
Comment 12•26 years ago
|
||
Setting all current Open/Normal to M4.
Updated•26 years ago
|
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Comment 13•26 years ago
|
||
Cut & paste work in the URL field now so apparently somebody fixed this but
didn't close the bug.
Updated•26 years ago
|
QA Contact: 1698
Comment 14•26 years ago
|
||
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.
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Comment 15•26 years ago
|
||
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•26 years ago
|
||
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.
Updated•26 years ago
|
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Comment 17•26 years ago
|
||
It was broken in AppRunner too but I fixed it anyway.
Comment 18•26 years ago
|
||
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•26 years ago
|
||
[Cut/Copy/Paste still nonfunctional in 3.15.99 builds.]
Comment 20•26 years ago
|
||
Per bug #3642, cut, copy & paste now work.
Mondo verification to follow on this bug shortly.
Comment 21•26 years ago
|
||
Bug 3642 lies. Deferring (again) on verification until the functionality is
functioning.
Updated•26 years ago
|
Whiteboard: Mar 24: Waiting for bug 3642 to be *really* fixed to verify
Updated•26 years ago
|
Whiteboard: Mar 24: Waiting for bug 3642 to be *really* fixed to verify → Mar 24: Waiting for bug 4147 to be *really* fixed to verify
Comment 22•26 years ago
|
||
Aha. This bug 4147 is actually the active bug for tracking the issue in 3642.
Updated•26 years ago
|
Whiteboard: Mar 24: Waiting for bug 4147 to be *really* fixed to verify → April 5: Waiting for bug 4147 to be *really* fixed to verify
Updated•26 years ago
|
Whiteboard: April 5: Waiting for bug 4147 to be *really* fixed to verify → April 9: Waiting for bug 4147 to be *really* fixed to verify
Updated•26 years ago
|
Whiteboard: April 9: Waiting for bug 4147 to be *really* fixed to verify → April 15: Waiting for bug 4147 to be *really* fixed to verify
Updated•26 years ago
|
Whiteboard: April 15: Waiting for bug 4147 to be *really* fixed to verify → April 20: Waiting for bug 4147 to be fixed in M6.
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Whiteboard: April 20: Waiting for bug 4147 to be fixed in M6.
Updated•26 years ago
|
Assignee: pinkerton → kostello
Status: REOPENED → NEW
Comment 23•26 years ago
|
||
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.
Updated•26 years ago
|
Resolution: FIXED → ---
Comment 24•26 years ago
|
||
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.
Updated•26 years ago
|
Assignee: kostello → karnaze
Comment 25•26 years ago
|
||
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.
Updated•26 years ago
|
Assignee: karnaze → pierre
Target Milestone: M4 → M6
Comment 26•26 years ago
|
||
Pierre, back to you, since it is MAC specific.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Summary: [PP] Copy and Paste in text widget need implementing on Mac → [PP][ENDER] Copy and Paste in text widget need implementing on Mac
Updated•26 years ago
|
Target Milestone: M6 → M9
Comment 27•26 years ago
|
||
Moving to M15 all the bugs that have a dependancy on GFX widgets and/or Ender.
Comment 28•26 years ago
|
||
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.
Updated•26 years ago
|
Assignee: pierre → saari
Status: ASSIGNED → NEW
Comment 29•26 years ago
|
||
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.
Updated•26 years ago
|
Summary: [PP][ENDER] Copy and Paste in text widget need implementing on Mac → [PP][ENDER] Copy/Paste in text widget not working from menus
Comment 30•26 years ago
|
||
resummarizing.
Comment 31•25 years ago
|
||
I really doubt this is a menu bug.
Reporter | ||
Comment 32•25 years ago
|
||
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•25 years ago
|
||
So who should this bug be assigned to?
Reporter | ||
Comment 34•25 years ago
|
||
This is some architecture work that needs to be done by someone in toolkit (or
perhaps apps). Redoing summary, reassigning to trudelle.
Reporter | ||
Comment 35•25 years ago
|
||
This is some architecture work that needs to be done by someone in toolkit (or
perhaps apps). Redoing summary, reassigning to trudelle.
Reporter | ||
Comment 36•25 years ago
|
||
This is some architecture work that needs to be done by someone in toolkit (or
perhaps apps). Redoing summary, reassigning to trudelle.
Reporter | ||
Comment 37•25 years ago
|
||
M15 seems awfully late to have this in. We need this for reasonalble GFX widget
handling, which is coming online any day now.
Assignee | ||
Comment 38•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
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.
Reporter | ||
Comment 41•25 years ago
|
||
you're teasing us hyatt! So what is a workable solution?
Comment 42•25 years ago
|
||
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•25 years ago
|
||
who should this be assigned to?
Comment 44•25 years ago
|
||
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.
Assignee | ||
Comment 45•25 years ago
|
||
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•25 years ago
|
||
Added dependency to Radha's URL bar cut/copy/paste feature, bug #4722, for beta.
Reporter | ||
Comment 47•25 years ago
|
||
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.
Assignee | ||
Comment 48•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: hyatt → buster
Comment 49•25 years ago
|
||
controller stuff is all ready for ya. saari is ironing out kinks in focus
still.
Updated•25 years ago
|
Whiteboard: [CODE cleanup]
Target Milestone: M12 → M14
Comment 50•25 years ago
|
||
moving this out to M14 -- code cleanup
Assignee | ||
Comment 51•25 years ago
|
||
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.
Updated•25 years ago
|
Summary: Need a way to talk to GFX widgets from JavaScript, for menu updating etc. → [DOGFOOD]Need a way to talk to GFX widgets from JavaScript, for menu updating etc.
Comment 52•25 years ago
|
||
ok, then we need to make this a DOGFOOD candidate -- adding dogfood to summary
Assignee | ||
Comment 53•25 years ago
|
||
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•25 years ago
|
||
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.
Assignee | ||
Comment 55•25 years ago
|
||
based on beth's criteria, I think this should go in M13.
Updated•25 years ago
|
Summary: [DOGFOOD]Need a way to talk to GFX widgets from JavaScript, for menu updating etc. → [BETA BLOCKER]Need a way to talk to GFX widgets from JavaScript, for menu updating etc.
Comment 56•25 years ago
|
||
removing DOGFOOD, putting in BETA BLOCKER, Steve already set it to 13.
Priority: P2 → P1
Summary: [BETA BLOCKER]Need a way to talk to GFX widgets from JavaScript, for menu updating etc. → Need a way to talk to GFX widgets from JavaScript, for menu updating etc.
Whiteboard: [PDT+] [by 12/3]
Target Milestone: M13 → M12
Assignee | ||
Comment 57•25 years ago
|
||
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•25 years ago
|
||
linking to 12658, composer pdt+ bug tracking
Assignee | ||
Comment 59•25 years ago
|
||
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)
Updated•25 years ago
|
QA Contact: elig → beppe
Comment 60•25 years ago
|
||
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.)
Assignee | ||
Comment 61•25 years ago
|
||
dev level fix, verifying. At a user level, it works in address book, where paul
has already hooked up the plumbing that uses this.
You need to log in
before you can comment on or make changes to this bug.
Description
•