Last Comment Bug 674770 - contenteditable breaks middle-click to open links when middlemouse.paste=true
: contenteditable breaks middle-click to open links when middlemouse.paste=true
Status: RESOLVED FIXED
[inbound][qa-]
: reproducible, testcase
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: mozilla11
Assigned To: Masayuki Nakano [:masayuki] (Mozilla Japan)
:
Mentors:
: 675551 (view as bug list)
Depends on: 732792
Blocks: contenteditable 392159 685395
  Show dependency treegraph
 
Reported: 2011-07-27 16:53 PDT by Matt Brubeck (:mbrubeck)
Modified: 2012-08-14 14:26 PDT (History)
16 users (show)
khuey: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
affected
affected
15+
fixed


Attachments
test case (238 bytes, text/html)
2011-07-27 16:53 PDT, Matt Brubeck (:mbrubeck)
no flags Details
Patch (v1) (4.60 KB, patch)
2011-07-28 14:42 PDT, :Ehsan Akhgari
roc: review+
Details | Diff | Splinter Review
Result of test_bug597331.html (3.06 KB, image/png)
2011-10-26 07:04 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details
Reference of test_bug597331.html (3.06 KB, image/png)
2011-10-26 07:05 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details
Result of test_bug600570.html (2.60 KB, image/png)
2011-10-26 07:06 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details
Reference of test_bug600570.html (2.60 KB, image/png)
2011-10-26 07:06 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details
Patch part.1 Shouldn't accept click event if the event target isn't in focused editor (6.74 KB, patch)
2011-10-27 18:52 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
ehsan: review+
Details | Diff | Splinter Review
Patch part.2 Fix new test_bug597331.html failure and test_bug600570.html failur on Windows (5.73 KB, patch)
2011-10-27 18:57 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
ehsan: review+
Details | Diff | Splinter Review
Patch part.2 -w (3.14 KB, patch)
2011-10-27 18:58 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review
Patch part.3 Add tests for middle-clicking on anchor element when the page has contenteditable element (3.52 KB, patch)
2011-10-27 18:59 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review
Patch part.4 Add new tests for pasting by middle click (13.21 KB, patch)
2011-10-27 19:07 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
ehsan: review+
Details | Diff | Splinter Review
part.1 Shouldn't accept click event if the event target isn't in focused editor (6.87 KB, patch)
2012-08-01 23:03 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
lukasblakk+bugs: approval‑mozilla‑esr10+
Details | Diff | Splinter Review
part.2 Fix new test_bug597331.html failure and test_bug600570.html failur on Windows (6.00 KB, patch)
2012-08-01 23:04 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
lukasblakk+bugs: approval‑mozilla‑esr10+
Details | Diff | Splinter Review
part.3 Add tests for middle-clicking on anchor element when the page has contenteditable element (3.62 KB, patch)
2012-08-01 23:04 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
lukasblakk+bugs: approval‑mozilla‑esr10+
Details | Diff | Splinter Review
part.4 Add new tests for pasting by middle click (13.37 KB, patch)
2012-08-01 23:06 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
lukasblakk+bugs: approval‑mozilla‑esr10+
Details | Diff | Splinter Review

Description Matt Brubeck (:mbrubeck) 2011-07-27 16:53:35 PDT
Created attachment 548972 [details]
test case

Steps to reproduce:
1. Open a page with both a contenteditable element and a link.
2. Middle-click the link.

Expected results: Link opens in a new tab.
Actual results: Nothing happens.

I first noticed this on Planet Mozilla today, where the inclusion of http://kazhack.org/?post/2011/07/27/Editor-Progress%3A-make-P%2C-not-BR! caused middle-click to break on the whole page.  I can reproduce the problem in versions of Firefox 5 through 8 on Ubuntu 11.04, using the attached minimal test case.
Comment 1 Alice0775 White 2011-07-27 21:03:01 PDT
Confirmed.WORKAROUND: middlemouse.paste to false.

I can also reproduce on Windows build if I set middlemouse.paste to true,

Regression window:
Works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a6pre) Gecko/20070627 Minefield/3.0a6pre
Fails:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a6pre) Gecko/20070628 Minefield/3.0a6pre
Pushlog:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-27+00%3A00%3A00&maxdate=2007-06-28+03%3A00%3A00&cvsroot=%2Fcvsroot

Suspected:
Fix for bug 237964 (Allow editable areas in browser (contentEditable)). r/sr=sicking.
Comment 2 :Ehsan Akhgari 2011-07-28 14:42:56 PDT
Created attachment 549232 [details] [diff] [review]
Patch (v1)
Comment 3 Alice0775 White 2011-07-31 20:29:40 PDT
*** Bug 675551 has been marked as a duplicate of this bug. ***
Comment 4 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-16 04:04:16 PDT
http://hg.mozilla.org/mozilla-central/rev/83b6f03bb285
Comment 5 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-16 04:11:41 PDT
And backed out

http://hg.mozilla.org/mozilla-central/rev/0220740e0bea
Comment 6 Alexander 2011-09-29 05:44:14 PDT
When will this bug get fixed? It still affects v7.
Comment 7 :Ehsan Akhgari 2011-09-29 12:21:21 PDT
The patch for this bug has not landed yet...
Comment 8 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-09-29 12:24:45 PDT
Well, it was landed, it got backed out for test failures though.
Comment 9 :Ehsan Akhgari 2011-09-29 12:28:00 PDT
Yes.  I've pushed it to try again to see what the test failures were.
Comment 10 Mozilla RelEng Bot 2011-09-29 18:02:36 PDT
Try run for e63afd4b940f is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=e63afd4b940f
Results (out of 157 total builds):
    exception: 1
    success: 131
    warnings: 12
    failure: 13
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-e63afd4b940f
Comment 11 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-12 07:59:41 PDT
Ehsan, what's the status of this bug? I'd like to change nsEditorEventListener::MouseClick() for other bugs. If you could, I'd like you to fix this bug first.
Comment 12 :Ehsan Akhgari 2011-10-12 08:21:18 PDT
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #11)
> Ehsan, what's the status of this bug? I'd like to change
> nsEditorEventListener::MouseClick() for other bugs. If you could, I'd like
> you to fix this bug first.

Sorry, totally forgot about it.  Just pushed it to inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/bc4f8b8d18b3

Out of curiosity, what changes are you planning to make to MouseClick?
Comment 13 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-12 08:35:54 PDT
(In reply to Ehsan Akhgari [:ehsan] from comment #12)
> Out of curiosity, what changes are you planning to make to MouseClick?

I think that we should update software keyboard open state when editor is clicked. If so, this bug's change may help better behavior of that.

But I'm still not sure whether the final patch changes the method because I'm still working on to make the new IME APIs which will be used for controlling the software keyboard state. See bug 685395.
Comment 14 :Ehsan Akhgari 2011-10-12 10:58:47 PDT
Backed out again due to test failure on Windows:

https://tbpl.mozilla.org/php/getParsedLog.php?id=6812430&tree=Mozilla-Inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/78085156d5da

I'll look at it again, maybe on Friday.
Comment 15 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-13 02:13:09 PDT
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=6e1bb2b92011

I tried to write a patch for bug 685395. The patch also fixes this bug and I don't see the same failure of test_bug597331.html. But I don't understand the actual cause...
Comment 16 :Ehsan Akhgari 2011-10-13 13:25:03 PDT
We need to take this patch for this bug, by checking IsModifiableNode.  The reftest failure is some sort of a focus issue, which I think is happening because we open a new tab in the test for this bug.  I've fought with that once before, and I don't think it's particularly tricky, I just need access to a Windows machine in order to reproduce and fix it.  :-)
Comment 17 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-13 20:58:48 PDT
Oh, OK. I see.

But your patch looks like preventing middle-paste on non-editable root element which has editable <body> (i.e., <html><body contenteditable></body></html>). Is that your intent? We are assuming that the root element is an editable element in such case. And my patch keeps the behavior.

I think that we shouldn't change IsModifiableNode() behavior anyway. That is used by very many if statement, so, changing it is very risky. I think that we should use nsEditor::IsAccepatbleInputEvent() for click event too, like my patch.
https://hg.mozilla.org/try/rev/f3983ee9bb72
Comment 18 :Ehsan Akhgari 2011-10-14 15:36:40 PDT
http://tbpl.mozilla.org/?tree=Try&rev=9f0409e91543
Comment 19 Mozilla RelEng Bot 2011-10-14 17:50:57 PDT
Try run for 9f0409e91543 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=9f0409e91543
Results (out of 3 total builds):
    success: 2
    warnings: 1
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-9f0409e91543
Comment 20 :Ehsan Akhgari 2011-10-15 10:27:05 PDT
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #17)
> Oh, OK. I see.
> 
> But your patch looks like preventing middle-paste on non-editable root
> element which has editable <body> (i.e., <html><body
> contenteditable></body></html>). Is that your intent? We are assuming that
> the root element is an editable element in such case. And my patch keeps the
> behavior.
> 
> I think that we shouldn't change IsModifiableNode() behavior anyway. That is
> used by very many if statement, so, changing it is very risky. I think that
> we should use nsEditor::IsAccepatbleInputEvent() for click event too, like
> my patch.
> https://hg.mozilla.org/try/rev/f3983ee9bb72

OK, yes, I think you're right.

So your patch should fix this bug as well, right?
Comment 21 Mozilla RelEng Bot 2011-10-15 13:40:51 PDT
Try run for 31ef02f4ca59 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=31ef02f4ca59
Results (out of 3 total builds):
    success: 2
    warnings: 1
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-31ef02f4ca59
Comment 22 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-16 19:28:14 PDT
(In reply to Ehsan Akhgari [:ehsan] from comment #20)
> So your patch should fix this bug as well, right?

Yes.
Comment 23 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-24 05:05:57 PDT
Hmm, I changed my mind, I'll separate the patch which can fix only this bug. We should fix this bug first.
Comment 24 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-24 05:28:20 PDT
Ehsan, would you post the latest your tests for this bug? I'll add the tests in my mq.
Comment 25 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-25 18:22:25 PDT
Hmm, I meet the same test failure without your new tests. I guess that there is another bug for the new failure. I'm looking for it...
Comment 26 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-26 07:04:18 PDT
Created attachment 569664 [details]
Result of test_bug597331.html
Comment 27 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-26 07:05:07 PDT
Created attachment 569665 [details]
Reference of test_bug597331.html
Comment 28 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-26 07:06:02 PDT
Created attachment 569666 [details]
Result of test_bug600570.html
Comment 29 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-26 07:06:45 PDT
Created attachment 569667 [details]
Reference of test_bug600570.html
Comment 30 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-26 07:09:52 PDT
The cause of the new failures is that the textareas don't have "focused" look-and-feel at their reference. I have no idea for the reason. Do you have any idea, Ehsan?
Comment 31 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-27 00:55:46 PDT
I see the cause of the new failures, I'll post all patches soon.
Comment 32 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-27 18:52:29 PDT
Created attachment 570147 [details] [diff] [review]
Patch part.1 Shouldn't accept click event if the event target isn't in focused editor

This checks whether the mouse event target is in focused editor or not.

Note that even if focus is moved to another element by focus event handler or mouse event handler, the editor still has focus when the IsAcceptableInputEvent() is called because focus will be actually moved by delayed focus event.

I'm not sure whether this is expected behavior or not. But at least, editor should not accept the mouse event for editing when the editor doesn't have focus.
Comment 33 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-27 18:57:19 PDT
Created attachment 570149 [details] [diff] [review]
Patch part.2 Fix new test_bug597331.html failure and test_bug600570.html failur on Windows

I think that the new failures are caused by delayed focus events. Therefore, the reference screenshots are captured before the textarea style is changed to :focus style. I'm not sure why my patch (and also your patch) causes changing the behavior.
Comment 34 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-27 18:58:22 PDT
Created attachment 570151 [details] [diff] [review]
Patch part.2 -w
Comment 35 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-27 18:59:59 PDT
Created attachment 570152 [details] [diff] [review]
Patch part.3 Add tests for middle-clicking on anchor element when the page has contenteditable element

This is your test (r=roc) but I changed the file name for next patch.
Comment 36 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-27 19:07:30 PDT
Created attachment 570155 [details] [diff] [review]
Patch part.4 Add new tests for pasting by middle click

For avoiding some test failures, this patch uses executeSoon a lot.

1. If focus() is called by script which is kicked by another DOM event, focus event may be delayed.
2. Pasting sometimes fails by synthesized mouse event, I'm not sure the reason. By delayed paste event?

And we should file a bug after this bug.

Middle click event is prevented and stopped by editor's event handler *before* web application handles it.

See XXX comment in nsEditorEventListener in the part.1 patch.
Comment 37 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-27 19:11:28 PDT
And on Mac, middle click paste doesn't work. I think that we should use global clipboard rather than primary selection on Mac.
Comment 38 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-10-27 19:28:26 PDT
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #37)
> And on Mac, middle click paste doesn't work. I think that we should use
> global clipboard rather than primary selection on Mac.

This is bug 392159.
Comment 39 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-11-22 18:17:16 PST
Ehsan:

ping.
Comment 40 :Ehsan Akhgari 2011-11-25 08:38:24 PST
Comment on attachment 570147 [details] [diff] [review]
Patch part.1 Shouldn't accept click event if the event target isn't in focused editor

Review of attachment 570147 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks!

(Sorry for my very long delay in getting back to you!)
Comment 41 :Ehsan Akhgari 2011-11-25 08:40:47 PST
Comment on attachment 570149 [details] [diff] [review]
Patch part.2 Fix new test_bug597331.html failure and test_bug600570.html failur on Windows

Review of attachment 570149 [details] [diff] [review]:
-----------------------------------------------------------------

I have no idea why the original failure happens, but they're indeed the side effect of something which is not important in this bug.  If these executeSoon calls let us proceed with this, then so be it!  :-)
Comment 42 :Ehsan Akhgari 2011-11-25 08:42:20 PST
Comment on attachment 570149 [details] [diff] [review]
Patch part.2 Fix new test_bug597331.html failure and test_bug600570.html failur on Windows

(BTW, please remove the reference and result data URIs from the test log message before landing.  While they're useful for debugging, they will clutter the successful test run logs needlessly.  Thanks!)
Comment 43 :Ehsan Akhgari 2011-11-25 08:49:18 PST
Comment on attachment 570155 [details] [diff] [review]
Patch part.4 Add new tests for pasting by middle click

Review of attachment 570155 [details] [diff] [review]:
-----------------------------------------------------------------

::: editor/libeditor/html/tests/test_bug674770-2.html
@@ +47,5 @@
> +// NOTE: tests need to check the result *after* the content is actually
> +//       modified.  Sometimes, the modification is delayed. Therefore, there
> +//       are a lot of functions and SimpleTest.executeSoon()s.
> +
> +addLoadEvent(function() {

I think you need to use waitForFocus when you call synthesizeKey.  Otherwise the test might fail intermittently on Linux.
Comment 44 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-11-25 20:57:10 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/dad793c1b143
https://hg.mozilla.org/integration/mozilla-inbound/rev/1a9cc49f9cf1
https://hg.mozilla.org/integration/mozilla-inbound/rev/1ab2c7d4c91d
https://hg.mozilla.org/integration/mozilla-inbound/rev/b5782f6da550

try:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=1c08af775d64

> (BTW, please remove the reference and result data URIs from the test log message before landing.  While they're useful for debugging, they will clutter the successful test run logs needlessly.  Thanks!)

The data URIs are undefined if the test succeed. Anyway, I changed the tests again. The landed patch outputs the data URIs only when it fails.

If we can still see the failure on inbound, I think we should disable the tests for now. I've looked similar failure on other bugs, so, I should fix the actual cause of the failure in another bug.
Comment 46 James Pearson 2012-07-18 07:39:04 PDT
The fixes in patch https://hg.mozilla.org/mozilla-central/rev/dad793c1b143 also fix problems we have with version 10 ESR on Linux using middle-button paste with OWA (Outlook Web App - Exchange 2010 Webmail)

The problem is that the text pasted via a middle-button paste is then not editable - i.e. if I middle-button paste some text in to the body of a new message, I can then not move the cursor in to that text - either using the mouse or the keyboard cursor keys i.e. the pasted text is displayed - but Firefox is unaware of it ...

I get a similar issue middle-button pasting in to the OWA search boxes

I have rebuilt 10.0.6 ESR on Linux with the above patch and it does indeed fix the problem

As middle-button pasting is quite common in the Linux world, I would like to have this fix incorporated in to 10 ESR
Comment 47 James Pearson 2012-07-26 04:16:10 PDT
Is this fix going to be added to the next ESR (10.0.7) release?
Comment 48 :Ehsan Akhgari 2012-07-31 11:31:43 PDT
Masayuki, would you mind preparing a rolled up version of the patch that applies cleanly on the ESR branch?  We're going to try to take this for the next ESR release.  Thanks!
Comment 49 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-01 01:22:28 PDT
The landed patches can apply to esr10 without any changes.

But I'll test them tomorrow. However, I'm not sure why this bug causes the behavior described in comment 46...
Comment 50 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-01 23:03:38 PDT
Created attachment 648228 [details] [diff] [review]
part.1 Shouldn't accept click event if the event target isn't in focused editor
Comment 51 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-01 23:04:05 PDT
Created attachment 648229 [details] [diff] [review]
part.2 Fix new test_bug597331.html failure and test_bug600570.html failur on Windows
Comment 52 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-01 23:04:33 PDT
Created attachment 648230 [details] [diff] [review]
part.3 Add tests for middle-clicking on anchor element when the page has contenteditable element
Comment 53 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-01 23:06:32 PDT
Created attachment 648231 [details] [diff] [review]
part.4 Add new tests for pasting by middle click

These patches works fine for me.

Test builds are:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/masayuki@d-toybox.com-6712854b20d3/

Unfortunately, failed to build on some platforms on tryserver. I guess that tryserver is using buildconfig for mozilla-central.
Comment 54 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-01 23:11:22 PDT
The result of tests:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=6712854b20d3

I tested with some testcases and on Outlook.

1. login to Outlook.
2. middle click in "Search email" field.
3. try modifying the pasted text.

Then, I don't see any problem in it. But I couldn't set focus (and also paste by middle click) to the editor of mail body at new mail composing. I'm not sure whether it's valuable to land these patches to ESR for Outlook.
Comment 55 James Pearson 2012-08-02 04:13:31 PDT
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #54)
> 
> Then, I don't see any problem in it. But I couldn't set focus (and also
> paste by middle click) to the editor of mail body at new mail composing. I'm
> not sure whether it's valuable to land these patches to ESR for Outlook.

Is the above before or after applying the patch?

Which version of OWA/Exchange are you using? Are you using the 'full' or 'light' interface to OWA (the problem isn't there with the 'light' version)

We definitely have a problem using middle-button paste with OWA 2012 and ESR 10.0.6 - but when I rebuild ESR 10.0.6 with this patch, the problems I described in comment #46 are fixed
Comment 56 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-02 06:35:12 PDT
I tested on outlook.com only with the tryserver build. Is the OWA you mentioned different from it?

Anyway, I'll be offline since now.

Ehsan, I confirmed the patches work fine for me. If you think that they should be landed on ESR, please request the approvals yourself. Thanks.
Comment 57 James Pearson 2012-08-02 06:43:15 PDT
No, we're using OWA (Outlook Web App) - which is the webmail client to Exchange 2010 - which is not outlook.com/hotmail webmail ...
Comment 58 James Pearson 2012-08-06 14:26:47 PDT
As there patches work fine with ESR 10 - can this fix be applied to the next ESR release?
Comment 59 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-07 20:32:43 PDT
Sorry for the delay, I'm back from my short vacation.

I'll request the approval.
Comment 60 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-07 20:45:53 PDT
Comment on attachment 648228 [details] [diff] [review]
part.1 Shouldn't accept click event if the event target isn't in focused editor

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:

See comment 46 and comment 55. I've never tested (confirmed) on it since I don't have such environment.

User impact if declined:

Uses cannot use middle click paste on some web applications. The middle click paste is common operation for Linux users. So, they must feel bad.

Fix Landed on Version:

Fx11.

Risk to taking this patch (and alternatives if risky): 

This patch added only the check if the event is fired on an editable element in the HTML editor. And I wrote the patch while mozilla-central was for Fx10. So, I tested with Fx10 when I worked on this. And following patches tests middle mouse event handling on editor.

String or UUID changes made by this patch: 

None.
Comment 61 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-07 20:47:16 PDT
Comment on attachment 648229 [details] [diff] [review]
part.2 Fix new test_bug597331.html failure and test_bug600570.html failur on Windows

[Approval Request Comment]
This is necessary for keeping tinderbox green if we pick part.1 up.
Comment 62 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-07 20:48:07 PDT
Comment on attachment 648230 [details] [diff] [review]
part.3 Add tests for middle-clicking on anchor element when the page has contenteditable element

[Approval Request Comment]
new tests for part.1.
Comment 63 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-08-07 20:49:23 PDT
Comment on attachment 648231 [details] [diff] [review]
part.4 Add new tests for pasting by middle click

[Approval Request Comment]
this is also additional new tests for part.1.
Comment 64 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-09 17:09:34 PDT
Comment on attachment 648228 [details] [diff] [review]
part.1 Shouldn't accept click event if the event target isn't in focused editor

Let's land this on ESR and then put out a call for some testing prior to release to make sure this is working as expected.
Comment 66 James Pearson 2012-08-10 06:19:22 PDT
(In reply to Lukas Blakk [:lsblakk] from comment #64)
> 
> Let's land this on ESR and then put out a call for some testing prior to
> release to make sure this is working as expected.

My problem is now fixed in the latest (10th August) nightly ESR build - thanks

Note You need to log in before you can comment on or make changes to this bug.