[BUG] LookupItem "Loading..." for customerid

EasyRepro Version

• Microsoft Dynamics 365 Online Version 8.2 (8.2.x) (DB 8.2.x) online
• Microsoft Dynamics 365 Online Version 9.0 (9.0.x) (DB 9.0.x) online
• Microsoft Dynamics 365 Online Version 9.0.2 (9.0.2) (DB 9.0.2) online
• Microsoft Dynamics 365 Online Version 9.1 (9.1.x) (DB 9.1.x) online

UCI or Classic Web

• UCI (XrmApp)
• Classic Web (XrmBrowser)

Online or On Premise

• Online
• On Premise

Browser

• Chrome
• Firefox
• IE
• Edge

While running the default CreateCaseUCI, at the step of setting the customerid, the browser stays at “Loading…” until it times out, instead of displaying the record. If I manually delete the last char and write it again, it finds the record and the test scenario ends correctly. I suspect it’s related to the value being typed too fast by selenium.

Here is what it looks like:

Code: LookupItem customer = new LookupItem { Name = "customerid", Value = "aaron aina", Index = 0}; xrmApp.Entity.SetValue(customer);

[dfo-elca]

Thanks.

I confirm it’s in the test UCITestCreateCase.

I let you know if I find a fix. I had this selenium speed idea because it can be reproduced also in CRM without using EasyRepro. Just copy/past a name in the LookUp field and it will do the same, but if you type it by hand, at a human pace, it works.

[jazzyuppal]

Hi,

Also facing this issue, running in Visual Studio 2019. Similar to others, the lookup appears but it just isn’t selected. An exception is generated:

Managed Debugging Assistant 'ContextSwitchDeadlock' Message=Managed Debugging Assistant 'ContextSwitchDeadlock' : 'The CLR has been unable to transition from COM context 0x6e19a8 to COM context 0x6e1a60 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.'

Code being run was:

xrmApp.Entity.ClearValue(new LookupItem { Name = "customerid" }); xrmApp.Entity.SetValue(new LookupItem { Name = "customerid", Value = "Jas Limited", Index = 0 });