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)

defect

Tracking

()

VERIFIED FIXED

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.
Assignee: sdagley → pierre
Handing off to pierre (core widget functionality)
Assignee: pierre → pinkerton
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.
I've done the Paste: you can add Cut and Copy.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Cut and Copy done for both text widget and text area widget. Marking fixed.
[pinged pinkerton to find out what 'text area' widget refers to.]
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.
Status: RESOLVED → REOPENED
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.)
...Unfortunately, TEXTAREA doesn't really work right now, so I can't really verify it. ;( See ya.
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.
Resolution: FIXED → ---
Clearing Fixed resolution
Inserting Milestone info.
Setting all current Open/Normal to M4.
Status: REOPENED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → FIXED
Cut & paste work in the URL field now so apparently somebody fixed this but didn't close the bug.
QA Contact: 1698
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.
Status: RESOLVED → REOPENED
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.
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.
Status: REOPENED → RESOLVED
Closed: 26 years ago26 years ago
It was broken in AppRunner too but I fixed it anyway.
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.
[Cut/Copy/Paste still nonfunctional in 3.15.99 builds.]
Per bug #3642, cut, copy & paste now work. Mondo verification to follow on this bug shortly.
Bug 3642 lies. Deferring (again) on verification until the functionality is functioning.
Whiteboard: Mar 24: Waiting for bug 3642 to be *really* fixed to verify
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
Aha. This bug 4147 is actually the active bug for tracking the issue in 3642.
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
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
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
Whiteboard: April 15: Waiting for bug 4147 to be *really* fixed to verify → April 20: Waiting for bug 4147 to be fixed in M6.
Status: RESOLVED → REOPENED
Whiteboard: April 20: Waiting for bug 4147 to be fixed in M6.
Assignee: pinkerton → kostello
Status: REOPENED → NEW
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.
Resolution: FIXED → ---
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.
Assignee: kostello → karnaze
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.
Assignee: karnaze → pierre
Target Milestone: M4 → M6
Pierre, back to you, since it is MAC specific.
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
Target Milestone: M6 → M9
Moving to M15 all the bugs that have a dependancy on GFX widgets and/or Ender.
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.
Assignee: pierre → saari
Status: ASSIGNED → NEW
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.
Summary: [PP][ENDER] Copy and Paste in text widget need implementing on Mac → [PP][ENDER] Copy/Paste in text widget not working from menus
resummarizing.
I really doubt this is a menu bug.
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.
So who should this bug be assigned to?
This is some architecture work that needs to be done by someone in toolkit (or perhaps apps). Redoing summary, reassigning to trudelle.
This is some architecture work that needs to be done by someone in toolkit (or perhaps apps). Redoing summary, reassigning to trudelle.
This is some architecture work that needs to be done by someone in toolkit (or perhaps apps). Redoing summary, reassigning to trudelle.
M15 seems awfully late to have this in. We need this for reasonalble GFX widget handling, which is coming online any day now.
OS: Mac System 7 → All
Hardware: Macintosh → All
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?
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?
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.
you're teasing us hyatt! So what is a workable solution?
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.
who should this be assigned to?
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.
Status: NEW → ASSIGNED
Target Milestone: M15 → M12
Assignee: trudelle → buster
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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.
Blocks: 4722
Added dependency to Radha's URL bar cut/copy/paste feature, bug #4722, for beta.
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.
Blocks: 13465
Blocks: 12022
Assignee: buster → hyatt
Status: ASSIGNED → NEW
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.
Assignee: hyatt → buster
controller stuff is all ready for ya. saari is ironing out kinks in focus still.
Status: NEW → ASSIGNED
Whiteboard: [CODE cleanup]
Target Milestone: M12 → M14
moving this out to M14 -- code cleanup
Whiteboard: [CODE cleanup]
Target Milestone: M14 → M12
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.
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.
ok, then we need to make this a DOGFOOD candidate -- adding dogfood to summary
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.
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.
Target Milestone: M12 → M13
based on beth's criteria, I think this should go in M13.
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.
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
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.
Blocks: 12658
linking to 12658, composer pdt+ bug tracking
Blocks: 20470, 20471
Status: ASSIGNED → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → FIXED
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)
No longer blocks: 20471
QA Contact: elig → beppe
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.)
Status: RESOLVED → VERIFIED
dev level fix, verifying. At a user level, it works in address book, where paul has already hooked up the plumbing that uses this.
No longer blocks: 13465
No longer blocks: 4722
You need to log in before you can comment on or make changes to this bug.