1815733 - Pasting into Outlook mail message (web version office 365) shows the [Paste] context menu

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Ben C]

Attachment: copypasteJPG.JPG

Steps to reproduce:

Tried computer restarts, logging off and back into Outlook 365, browser refresh. All done on multiple computers both PC and MAC.
Issue is only in firefox. Other browsers work.

Actual results:

I cannot paste into an Outlook mail message (web version office 365) in firefox v109.0.1.
The paste function (right click) works one time and then the option does not appear again. If I refresh the page it works one time and then no more again.
ctrl+v does work.

Expected results:

paste should work more than one time

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[jonzn4SUSE]

Attachment: right click paste in outlook_Screenshot 2023-02-11 210901.jpg

I can replicate the issue, but it's inconsistent even in Safe Mode with ETP off.

Edition Windows 11 Pro Insider Preview
Version 22H2
Installed on ‎03-‎Feb-‎23
OS build 25290.1000
Experience Windows Feature Experience Pack 1000.25290.1000.0

Comment 3

[Bas Schouten (:bas.schouten)]

This does not appear to be a performance issue.

Comment 4

[Jens Stutte [:jstutte]]

As Ctrl+v works, I'd propose to start investigation from Firefox UI side.

Comment 5

[Negritas Sergiu, Desktop QA]

Hello I have managed to reproduce the issue with firefox 112.0a1(2023-03-09), 111.0 and 110.0.1 on Ubuntu 22.04, I will mark this issue as NEW in order for our developers to get involved and update the corresponding flags.

Have a nice day!

Comment 6

[Sam Foster [:sfoster] (he/him)]

This feels like a webcompat issue, but feel free to move it back if that's not the case.

Comment 7

[jonzn4SUSE]

I'm also still able to reproduce in Windows 11 and openSUSE in 112.0.1.

Operating System: openSUSE Tumbleweed 20230420
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.8
Kernel Version: 6.2.10-1-default (64-bit)
Graphics Platform: X11
Processors: 12 × Intel® Core™ i7-9850H CPU @ 2.60GHz
Memory: 125.1 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 630
Manufacturer: HP
Product Name: HP ZBook 17 G6

Comment 8

[Calin Tanase]

Attachment: right click paste text FF vs Chrome.mp4

Verified this issue and it's still reproducible on Firefox versions 122 and 124 in a certain way. It requires clicking on multiple paste buttons until it eventually gets pasted. Check the attached video for a better understanding.

Environment:
Operating system: Windows 10
Browsers: Firefox Nightly 124.0a1 (2024-01-28) / Firefox Release 122 / Chrome 121.0.6167.86

Note: Not reproducible on Chrome

Comment 9

[u752148]

I had to enable dom.events.testing.asyncClipboard to get the paste function to work properly on Outlook.

Comment 10

[Thomas M Steenholdt]

(In reply to kakekikoku from comment #9)

I had to enable dom.events.testing.asyncClipboard to get the paste function to work properly on Outlook.

This solved the problem for me too.

Comment 11

[Tom Schuster]

Just fyi so you are aware of this. I've seen at least two people on Outlook mentioning this issue.

Comment 12

[Tom Schuster]

The alternative is that I can't use Firefox at work because I can't compose emails in web Outlook. You're telling me to use Edge/Chrome basically.

https://www.reddit.com/r/firefox/comments/1dofgd2/pasting_into_web_outlook_popping_up_little_paste/ladg7e5/

Comment 13

[Edgar Chen [:edgar]]

I can also see this when pressing ctrl+v to paste something in the email compose box. The text is pasted, but the paste button shows as well, which means the page calls clipboard.read() even when the page has got the clipboard data from paste event, which doesn't make sense to calls clipboard.read() again. And I also see the paste button shows when right click the page, and then page shows their context menu only after user interact with the paste button, I think Outlook wait for the clipboard.read() result before showing the page's context menu.

:denschub, can we contact with Outlook people to understand why they are calling clipboard.read() to try to read clipboard data at those point, which could break the user work flow. I would expect page only calls clipboard.read() only when user really ask for reading clipboard data.

Comment 14

[Edgar Chen [:edgar]]

Safari, which has the same security model as Firefox, doesn't show the paste button when the user presses Ctrl+V to paste. And the paste button isn't shown when user right-click the page to open outlook's context menu, either. So it seems to me that Outlook doesn't call clipboard.read() on Safari at those point. I guess maybe Outlook does different things on Firefox and Safari based on the UA string or such?

Comment 15

[Edgar Chen [:edgar]]

I tried to change the UA string to Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Safari/605.1.15, but it doesn't help.

Comment 16

[Hsin-Yi Tsai (she/her)[:hsinyi]]

It may depend on the response or how quickly we will get from the Outlook folks; however I wonder if there is another workaround in addition to temporarily disabling clipboard.read() only for outlook. While the copy/paste functionality isn't necessarily broken, breaking the user work flow is a significant regression imo.

Comment 17

[Edgar Chen [:edgar]]

(In reply to Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi] from comment #16)

It may depend on the response or how quickly we will get from the Outlook folks; however I wonder if there is another workaround in addition to temporarily disabling clipboard.read() only for outlook. While the copy/paste functionality isn't necessarily broken, breaking the user work flow is a significant regression imo.

I filed bug 1906285 to support disabling clipboard.read() from domain list.

Comment 18

[Sky Schubert [:skyschub]]

I have marked two comments here as off-topic. Specifically, comments suggesting to flip dom.events.testing.asyncClipboard to true. This is a fundamentally bad idea. This pref was meant for automated testing, and bypasses all security/permission checks on clipboard access. If you toggle this pref, any site has full access to your clipboard all the time without asking you or you even noticing, do not touch that pref.

Comment 20

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Edgar Chen [:edgar] (Parental leave until Oct. 09.) from comment #17)

(In reply to Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi] from comment #16)

It may depend on the response or how quickly we will get from the Outlook folks; however I wonder if there is another workaround in addition to temporarily disabling clipboard.read() only for outlook. While the copy/paste functionality isn't necessarily broken, breaking the user work flow is a significant regression imo.

I filed bug 1906285 to support disabling clipboard.read() from domain list.

Bug 1906614 said the issue started with Fx 124, while I was confused with the version, as clipboard.readText() was shipped in Fx 125. But since we implemented the same privacy model with a context menu for .readText(), we should also keep .readText() in mind, in addition to .read().

Comment 21

[Tom S. (please needinfo tschuster)]

I think you are right the original issue is about paste not working at all instead of the [Paste] context menu. I am not sure the original issue can happen anymore, so I am not sure if we need to split it up again.

Comment 22

[Sky Schubert [:skyschub]]

Attachment: Bug 1815733 - Override navigator.clipboard.read() with a no-op for Outlook. r?twisniewski

Comment 23

[Sky Schubert [:skyschub]]

I attached a working intervention. It replaces navigator.clipboard.read() with a function that does nothing except for returning a resolving Promise. It looks like Outlook isn't actually using the returns in the code paths we hit, and pasting in content works just fine. I didn't add a override for readText() as suggested by Hsin-Yi - there is only one call to this function in all of MS' code, and we don't seem to hit that codepath in any of my tests. We can, of course, always add this later.

I'll leave webcompat:needs-diagnosis on this bug, as I think we should actually understand and document the behavioral difference between browsers here, but this intervention seems like a good solution for now.

I'll land this soon, and probably also uplift it into 129, as there should be very little risk.

Comment 24

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Thanks Dennis!

Comment 25

[Donal Meehan [:dmeehan]]

Tracking since there's a hope to get this into Fx129. There's not much time left though since Fx129 goes to RC next week.
Appreciate getting an uplift request on this as soon as you're ready.

:hsinyi/:denschub what about 128esr? Wondering if it's save to fix there also?

Comment 26

[Hsin-Yi Tsai (she/her)[:hsinyi]]

I think we should fix this in ESR 128 as well. I will delegate to Dennis to confirm the risk of uplifting there.

Comment 27

[Sky Schubert [:skyschub]]

I'm not landing this now because I want to avoid conflicting with bug 1909241, which is more important. I will rebase and land my patch as soon as that is done. I planned to uplift this, but this is a 2 year old bug, so it's not like this is super urgent.

If my patch lands in central before EOD tomorrow, I'll immediately file an uplift request. But if it's later, that's fine, too, we can leave this in 130 and not ship to 128 - or maybe uplift it into release and ride along a dot-release.

Uplifting into esr128 makes sense to me - Outlook is probably used a lot by ESR users. The risk seems low, we're no-op'ing an API that we previously didn't ship, and Outlook seems to work fine in my tests. I'll file the uplift request on a dedicated patch for ESR as soon as the other work is done.

Does that work for you?

Comment 28

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Dennis Schubert [:denschub] from comment #27)

I'm not landing this now because I want to avoid conflicting with bug 1909241, which is more important. I will rebase and land my patch as soon as that is done. I planned to uplift this, but this is a 2 year old bug, so it's not like this is super urgent.

As comment 21 mentioned, the scope of this bug is actually mixed.
The original issue is about paste not working at all instead of the [Paste] context menu. while the new regression/complaints since recent Fx 127
was about causing a super annoying working flow, where users had to close an unexpected button before they can continue the normal editing flow.

If my patch lands in central before EOD tomorrow, I'll immediately file an uplift request. But if it's later, that's fine, too, we can leave this in 130 and not ship to 128 - or maybe uplift it into release and ride along a dot-release.

Uplifting into esr128 makes sense to me - Outlook is probably used a lot by ESR users. The risk seems low, we're no-op'ing an API that we previously didn't ship, and Outlook seems to work fine in my tests. I'll file the uplift request on a dedicated patch for ESR as soon as the other work is done.

Does that work for you?

Comment 29

[Sky Schubert [:skyschub]]

Ah you're right. Having two bugs in one is confusing, and I forgot that detail.

I'll absolutely try to get this into 129 then - either tomorrow or early Monday after that other patch landed, or as a later uplift into a dot-release ride-along. :)

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ffc943892e26
Override navigator.clipboard.read() with a no-op for Outlook. r=twisniewski,webcompat-reviewers

Comment 31

[Sky Schubert [:skyschub]]

Attachment: Bug 1815733 - Beta 129 - Override navigator.clipboard.read() with a no-op for Outlook.

Comment 32

[Sky Schubert [:skyschub]]

Attachment: Bug 1815733 - Beta 129 - Override navigator.clipboard.read() with a no-op for Outlook.

Original Revision: https://phabricator.services.mozilla.com/D217969

Comment 33

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Annoying "paste" overlay when the user pastes text. This native browser UI overlay steals focus, and this is annoying.
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Paste something into a new Outlook email. There should be no "Paste" dialog.
• Risk associated with taking this patch: Low
• Explanation of risk level: The intervention only affects Outlook domains. In case of an exception inside the addon, the addon wouls just stop working.
• String changes made/needed: No
• Is Android affected?: yes

Comment 34

[Sky Schubert [:skyschub]]

Attachment: Bug 1815733 - ESR 128 - Override navigator.clipboard.read() with a no-op for Outlook.

Comment 35

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Annoying "paste" overlay when the user pastes text. This native browser UI overlay steals focus, and this is annoying.
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Paste something into a new Outlook email. There should be no "Paste" dialog.
• Risk associated with taking this patch: Low
• Explanation of risk level: The intervention only affects Outlook domains. In case of an exception inside the addon, the addon wouls just stop working.
• String changes made/needed: no
• Is Android affected?: yes

Comment 36

[Phabricator Automation]

release Uplift Approval Request

• User impact if declined: Annoying "paste" overlay when the user pastes text. This native browser UI overlay steals focus, and this is annoying.
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Paste something into a new Outlook email. There should be no "Paste" dialog.
• Risk associated with taking this patch: Low
• Explanation of risk level: The intervention only affects Outlook domains. In case of an exception inside the addon, the addon wouls just stop working.
• String changes made/needed: No
• Is Android affected?: yes

Comment 37

[Sky Schubert [:skyschub]]

This patch isn't in Nightly yet, but I ran local builds for Nightly, the 129 tree, and ESR128 and confirmed that the patch is working as expected.

The "Is Android affected?: yes" is actually wrong - the patches are changing code in the Mobile tree, but that's only to keep the codebases in sync and make diffs less confusing. The intervention isn't actually running on mobile, and the bug itself is also only affecting Desktop.

Comment 38

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/ffc943892e26

Comment 39

[Donal Meehan [:dmeehan]]

:denschub are you planning on tracking any more patches here?
It's not resolved since it has a leave-open keyword. It will make it difficult to track across releases if anything else is added here.

Comment 40

[Sky Schubert [:skyschub]]

I added leave-open so we can keep this bug to track eventual outreach attempts. That being said, I will file a new bug if I figure out the actual browser difference here, and we can use that new bug. This bug is already overloaded with too much stuff. Removing leave-open and marking as fixed per the central-landing in comment 38.

Comment 41

[Peter Magyari (Desktop QA)]

The "extra" paste dialog no longer appears when attempting to paste something into the outlook mail message using the context menu or keyboard shortcut. I've verified this using the build form Comment 38 (Nightly 130.0a1 - 20240730095146)

However pasting doesn't work from the context menu yet (the original issue on which this bug was filed on)
Did you manage to log a new issue for that, Dennis?

Perhaps the title of this report should be updated to clarify what was fixed here, so it isn't confusing.

Thanks!

Comment 42

[Tom S. (please needinfo tschuster)]

I renamed this bug and opened bug 1910878 for the original issue with paste not working from the context menu.

Comment 43

[Peter Magyari (Desktop QA)]

Thanks Tom!

Comment 44

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/7cfdc30bf238

Comment 45

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/e24fe9db622c

Comment 46

[Peter Magyari (Desktop QA)]

Verified fixed using Firefox 129.0 (20240731192623) and Firefox 128.1.0esr (20240731223332) on Windows 10, MacOS 14.4.1 and Ubuntu 24.04.