Closed Bug 46867 Opened 20 years ago Closed 19 years ago
IClipboard Commands (or a generic command dispatch API) needs to be implemented .
4.35 KB, patch
|Details | Diff | Splinter Review|
You get it by doing a GetInterface on the web browser object. nsIContentViewerEdit is not needed. nsIClipboard is a lower-level interface that we might want to expose as well for X selection. SelectNone() semantics need to be specified - where is the insertion point (collapsed selection) CanPasteSelection() should be renamed to CanPaste() PasteSelection() should be renamed to Paste()
*** Bug 45601 has been marked as a duplicate of this bug. ***
Assignee: valeski → rpotts
The nsIClipboardCommands & nsIContentViewerEdit interfaces are practically identical. I think they should be consolidated into a single interface. BTW the current implementation of nsIClipboardCommands on the nsWebshell doesn't do anything at all.
per email with Jud, changing nsbeta3+ to nsbeta3- on all "embed" keyword bugs since embedding changes will not be made in the mn6 branch. If you feel this bug fix needs to go into mn6 branch, please list the reasons/user impact/risk and nominate for rtm. Thanks.
Whiteboard: [nsbeta3+] → [nsbeta3-]
over to casa de pink
Assignee: rpotts → pinkerton
Target Milestone: --- → mozilla0.9
Pink: please add swag to status whiteboard
We need text fields (form as well as composer content areas) in content areas to be able to support cut/copy/paste when embedded. HTML content areas (static) need to support "copy." It would be helpful to have an understanding of how much of this relies on XUL (and in what areas) and how much doesn't.
none of the clipboard stuff relies on XUL. I'm not sure what you need from me here. What needs to be written apart from what is already written?
on the trivial end, method renaming suggested above. pavlov, you had a lot of input on this topic in the api review meeting that generated this bug. More specifically, how do we differentiate between selection level copy on linux, vs. ctrl-c copies. Does the current iface accommodate?
i said that people should use nsIClipboard and avoid nsIClipboardCommands all together.
i guess the goal of nsIClipboardCommands is that to handle a paste from the app, the embedding app shouldn't have to know how to get the HTML text field and how to put the data into it. All i plan on doing is to make these calls use the commandDispatcher to dispatch the appropriate command to the currently focussed widget, then we won't have to write a bunch of special-case code.
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: [nsbeta3-] → [nsbeta3-] SWAG: 3 days
notes to self: implement (from globalOverlay.js), |goDoCommand()| and |goUpdateCommand()| in C++ to send the relevant command string to the focussed object.
so you're saying that it's up to us to handle an internal cut/copy->paste (works for me), but what if I (an embedding app) want to copy a URL from the content area (us) and paste it into my URL bar? Should this bug depend on this cmdDispatcher bug? http://bugzilla.mozilla.org/show_bug.cgi?id=54203 Consider what functionality an embedding app is going to want/need. They're going to want to cut/copy/paste, just like we do.
jud, the embedding app needs to know when something in our embedded area is focussed in order to call our API, or to handle it itself. Once that is covered, what you mentioned should be a no-brainer.
Depends on: 54203
after talking to hyatt, we decided that instead of having specific command dispatch APIs for different functionality, we should just come up with a single generic one. It will certainly be needed for things other than just clipboard, and then we can obsolete nsIClipboardCommands. cc'ing hyatt and adam lock.
Summary: nsIClipboardCommands needs to be implemented. → nsIClipboardCommands (or a generic command dispatch API) needs to be implemented.
if what adam says is the case, then I will cvs remove nsIClipboardCommands and mark this bug invalid. arguments?
Don't mark it invalid. This is tracking the embedding need for clipboard support. It sounds like this may not have been adequately defined and documented for embedders, perhaps that is all that remains.
Wait up. I recall, in one API review meeting I was at, that people said that we should provide functionality-specific command handling interfaces for embedders. I.e. that we *do* provide things like nsIClipboardCommands, instead of generic "do named command" type interfaces. Judson, Doug -- comments?
Why would we need to complicate things with additional interfaces though?
who was asking for these additional interfaces? Can someone answer hyatt's question? I need to know if there is work to be done, or not.
the api changes fell out of a mozilla porkjockeys meeting a few months ago. We glossed over this one w/ out going into too much detail because it seemed hard. I'm going to forward this bug to porkjockeys so we can open this up for discussion again.
i have the code written (figured i might as well, it was easy). How do i go about testing any of it?
can someone r= the attached patch to nsWebShell? I've noticed that none of the test harnesses use it, so I can't really test it.
Webshell is an evil thing and I'm not sure I like the idea of it growing again. Should this stuff be moved into docshell or would that bad too? Also, if we're covering a generic interface (nsIController) with a custom interface (nsIClipboardCommands), then perhaps webshell (or docshell) should also implement nsIController so people can inject the string commands directly.
whatever. i just filled in the stubbed out interface. if you guys want the code elsewhere, let me know.
ok, conrad added some stuff to the mac embedding harness and the new clipboard commands do actually work! Note, in the diff above, I had to prefix the commands with "cmd_" to get it to work.
Whiteboard: [nsbeta3-] SWAG: 3 days
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
so am I able to get the nsIClipboardCommands interface from the webbrowser object?
re-opening as the methods haven't been renamed (as outlined in the first comment of the bug). the concept of "selection" isn't valid in the iface anymore (it's implicit).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9 → mozilla0.8
i've made the changes. the semantics of SelectNone() are that the insertion point is at the beginning of the previous selection. If you disagree, speak up. It's easy to change.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Updating QA Contact
QA Contact: jrgm → mdunn
Test with WinEmbed.exe
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.