Click Event Triggers on Complex Buttons are ignored in some environments

[ericdrobinson]

Version

2.6.10

Reproduction link

https://jsfiddle.net/s7hyqk13/2/

Steps to reproduce

1. Configure one of the Adobe CEP Sample Panels. The PProPanel is a good starting point as it has very clear documentation on how to set up the environment for testing.
2. Replace the HTML/JavaScript/CSS contents of the panel project with the contents of the linked JSFiddle.
3. Open the panel.
4. Attach a debugger (with the default PProPanel setup this would mean browsing to localhost:7777 in Chrome).
5. Set the "Mouse > click" Event Listener Breakpoint in the "Sources" tab of the Chrome Debugger.
6. Click the Vue icon in the center of the silver div.

What is expected?

Method bound to the @click handler is triggered when the image embedded in the parent div is clicked.

What is actually happening?

The method bound to the @click handler is only triggered when clicking outside of the parent div.

---

This is a non-trivial bug to reproduce as the only place I've experienced it is in Adobe CEP extensions (which run NW.js under the hood). That said, it does reproduce 100% of the time there.

The debugger (CEP context) seems to show several funny things at around this line in the Vue events.js file. Specifically:

1. The e.timeStamp value does not change between callbacks for different buttons/elements.
2. The attachedTimestamp is significantly larger than the e.timeStamp value.
3. The attachedTimestamp value does change when the component is updated (the e.timeStamp remains identical).

I should note that this affects at least CEP 8.0 and CEP 9.0 (tested in Premiere Pro).

Vue Versions Note: This broke somewhere between versions 2.5.17 and 2.6.x. If we run a version of 2.5 (2.5.17 and some earlier versions verified), then this issue does not occur. In testing 2.6.x, we've found that this same issue occurs from 2.6.5 to 2.6.10 (latest). Versions of 2.6 prior to 2.6.5 are actually worse in that the buttons basically don't work at all.

Important Note: I should further note that apparently right-clicking to open the basic CEF [not CEP] context menu will cause the e.timeStamp values to begin reporting as expected. Once this occurs, the buttons will also work as expected. That said, we shouldn't have to instruct users to right-click prior to interfacing with the extension.

[posva]

I don't own Photoshop so I won't be able to test nor debug this problem. Can it be on nw.js as well? Maybe that could be tested

[ericdrobinson]

@posva As a quick note, this issue isn't restricted to Photoshop. Just about every major Creative Cloud application supports CEP extensions - and is affected by this problem. 😕

[ericdrobinson]

right-clicking to open the basic CEF [not CEP] context menu will cause the e.timeStamp values to begin reporting as expected.

It appears that this isn't quite right. The e.timeStamp value is updated when a right-click occurs. However, subsequent callbacks will then report the same updated value. This is, at least, what the following extremely simple test case shows:

window.addEventListener('click', (evt)=>{console.log(evt.timeStamp);});

This means that a post right-click event will work as expected as long as the attachedTimestamp isn't reset! It appears that once a "flush" occurs and the event listener is re-attached, the issue reappears (until the next right-click).

[ericdrobinson]

I should point out that it is possible to distinguish a CEP environment and version with standard JavaScript calls. This may be helpful for adding an environment flag.

Specifically, the following snippet is designed to be inserted into the existing environment flag setup:

const  isAdobeCEP = inBrowser && typeof window.__adobe_cep__ !== undefined;

The __adobe_cep__ object also has the getCurrentApiVersion native function, which returns the CEP version encoded as a JSON string. See:

// In Premiere Pro 13.1.3, outputs: "{"minor":3,"micro":1,"major":9}"
window.__adobe_cep__.getCurrentApiVersion();

The version JSON returned by this function may be easily parsed and accessed:

const cepVersion = JSON.parse(window.__adobe_cep_.getCurrentApiVersion());

cepVersion.major; // = 9
cepVersion.minor; // = 3
cepVersion.micro; // = 1

Hopefully this will prove helpful in some way.

[Inventsable]

I made a standalone panel to demonstrate this but don't get the same behavior on Windows 10 and Vue 2.6.10, but I don't have a Mac to test:

Any Mac user should be able to run a single terminal command: defaults write com.adobe.CSXS.9 PlayerDebugMode 1, then clone the repo into the specified directory in the README and open it in Illustrator, After Effects, Photoshop or Premiere Pro via Windows > Extensions > clicktest, then access the CEF debugger easily via the right-click context menu on the panel.

---

EDIT: Eric corrected me on the version, this is 2.6.10 (not 2.6.1)

[ericdrobinson]

[Update: Please see this comment for more on the struck-through text below.]

Thanks to @Inventsable I was able to narrow down the test case a bit more. In order to experience the issue I described, a click event handler must be installed on the contained element (in this case, an <img> element) as well as the container. I have updated the JSFiddle link in the issue description.

[For the record, this was the previous version and this is the adjusted version.]

Also, @Inventsable was able to verify that the timeStamp value appears to update correctly when run in Windows applications. I've tested on macOS-based Premiere Pro and can verify that the timeStamp issue does occur there (even in the graciously provided bug report panel).

[derrickb]

This is affecting me as well.

• Vue 2.6.10
• Photoshop CC 2019
• macOS 10.14.6

Thank you @ericdrobinson for filing this issue!

[ericdrobinson]

Update: My previous comment about requiring a contained element to also have an event handler was 100% a red herring. This is entirely unnecessary to get the bug to reproduce.

It appears that small, fast-loading scripts result in the reported event timeStamp being 0. This is unfortunate because it obscures the bug by passing as expected here.

On macOS, the event timeStamp value only increments when a right-click occurs to open a native context menu (provided it's not been disabled, of course). Great. The problem now is that the "attachedTimestamp" is properly less than the currently-constant timeStamp. We need a way to ensure that the following occurs:

1. The Event.timeStamp value is greater than 0.
2. The attachedTimestamp is greater than the Event.timeStamp.

That's easy: have the user right-click anywhere and then trigger some code that attaches a new listener!

I've adjusted the JSFiddle example to account for the above to ensure a 100% reproduction rate in Adobe CEP applications (e.g. Photoshop, Premiere Pro, Illustrator, InDesign, After Effects, etc.) running on macOS.

[ericdrobinson]

I don't own Photoshop so I won't be able to test nor debug this problem. Can it be on nw.js as well? Maybe that could be tested

@posva We've narrowed the repro for this down to Adobe CEP contexts running on macOS. Adobe is aware of the problem but a fix from them will not address released applications.

From what I can gather by reading this comment from @yyx990803 on #6566, there is an issue here in event dispatch/processing with respect to the micro/macro task order.

Further, it appears that the code has subsequently been updated with a few workarounds "for environments that have buggy event.timeStamp implementations".

It appears that the workaround for the event ordering issue that was implemented in ba0ebd4 to address #6566 ended up breaking things for CEP-on-macOS (as it did with a few other "broken environments").

I would then propose that a solution would be to follow the examples set in 0bad7e2 and 7591b9d and simply bail out of this special-case processing when we detect that we're in the "broken environment" that is CEP-on-macOS. This can be done like so:

1. Add the following to env.js

   export const isCEP = inBrowser && window.__adobe_cep__;

2. Add the following to events.js

   // #10366 Adobe CEP bug: event.timeStamp is not reliable
   isCEP ||

You will note that the above solution does not distinguish between macOS and Windows hosts (the latter of which does not have this issue). This would be for cross-platform consistency. It could easily be amended to check for macOS with something akin to the following:

/mac/.test(window.navigator.platform.toLowerCase()); // True on macOS; false otherwise.

I have tested this locally and the above does appear to resolve the issue. Thoughts? Concerns?

[posva]

I imagined it would be that, that's why I was asking about a nw.js version that we could target
It is weird that it doesn't appear on windows though, it would be worth seeing the differences in terms of user agent between them

[ericdrobinson]

I have no idea about whether nw.js would be similarly affected. Someone internal at Adobe would need to chime in there. @bbb999 perhaps?

The User Agent reported for Premiere Pro 13.1.4 on macOS 10.14.6 is as follows:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

I've asked others if they can provide the Windows equivalent. Given that the only difference between CEP's User Agent and the Chrome browsers' is the Chrome version, I'd be willing to bet it looks identical to a standard Windows Chrome User Agent for Chrome 61.0.3163.91...

[ericdrobinson]

@posva Here are the two User Agent versions:

From After Effects 16.1.2 on Windows 10:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

From Premiere Pro 13.1.4 on macOS 10.14.6:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

The CEP version determines the User Agent. See this table for a rough outline.