<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 16, 2014 at 5:52 AM, Neil <span dir="ltr"><<a href="mailto:neil@parkwaycc.co.uk" target="_blank">neil@parkwaycc.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Ehsan Akhgari wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2014-09-15, 5:20 PM, <a href="mailto:hallvors@gmail.com" target="_blank">hallvors@gmail.com</a> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Which parts specifically?  If you find unimplemented parts, please file bugs.  I think we have most of it implemented already.<br>
</blockquote>
<br>
I plan to do some deeper testing and bug reporting soon. I know some details (like commands not always being enabled when I would like them to be - it would be good if for example ctrl-v would always fire a "paste" event regardless of whether there is a cursor/editable context or not - and this issue prevents several of my tests from being testable.. But I plan to report a few bugs :)).<br>
</blockquote>
<br>
Oh, yeah, that issue is actually known.  Currently we don't dispatch those events if the corresponding command is disabled.  I think the right thing to do would be to dispatch the events always, but bail out early on the default action if the command is disabled.  That way, if the command is disabled, content can still receive these events.<br>
<br>
The issue that makes that a bit hard to fix is that right now the Ctrl+X/C/V are bound to XUL commands, which we disable/enable as the current selection changes.  This stuff is triggered on the Gecko side by calling nsGlobalWindow::UpdateCommand(<u></u>"select") in nsDocViewerSelectionListener::<u></u>NotifySelectionChanged.  That ends up calling goUpdateGlobalEditMenuItems in toolkit, which currently updates the cmd_cut/copy/paste commands.  I think we'd want to instead update the corresponding menu items and toolbar keys.  But these are well known commands in XUL applications, I don't know we can simply change toolkit here.  CCing dev-firefox and Neil, hopefully someone can check over my idea here.<br>
</blockquote>
<br></div></div>
Actually the key elements are only for show, see <a href="http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/editMenuOverlay.xul#31" target="_blank">http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/editMenuOverlay.xul#31</a><br></blockquote><div><br></div><div>Hehe, nice! :-)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We need the commands to be up-to-date so that the menuitems can be disabled correctly, and also toolbar buttons where appropriate (offhand I don't know whether Firefox uses this), and more importantly the Mac menu also depends on the commands being up-to-date.<br>
<br>
What might work is to change the command controller API so that you don't need to check that the command is enabled before attempting to invoke it. (Obviously you would have to fix all the implementations in mozilla-central and at least warn comm-central too please.) Then you could make the XBL and native keys simply invoke the command directly, and then you could make Ctrl+X/C/V always fire the appropriate event first. (Because of the way contenteditable works, you would need to add dummy cut and paste handlers to the global window commands for uneditable documents which just fired the event and did nothing and always claimed to be disabled.)<br>
</blockquote></div><br></div><div class="gmail_extra">I don't think that will give us exactly what we want though.  The desired outcome is for the commands themselves to be *always* enabled, they just need to do nothing if you invoke them in contexts that they are currently disabled in, except for dispatching the events.  But the tricky thing is that other XUL based apps may not want to have these commands always enabled...<br clear="all"></div><div class="gmail_extra"><br>-- <br><div dir="ltr">Ehsan<br></div>
</div></div>