[BUG] Quick Create Form Does Not Populate

[rswafford]

Bug Report

Issues should only be created for items related to covered functionality.

Not covered functionality, feature requests, and questions should use the Feature Request or Question templates.

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

Describe the bug
I have created a test case that opens a Quick Create form and attempts to populate required fields. The code I'm using is below. It fails on the first _xrmApp.QuickCreate.SetValue line, with the error message "MoveToElement cannot move to a null element with no offset. Parameter name: toElement"

Special formatting / display

Code to reproduce

var _client = new WebClient(TestSettings.Options);
var _xrmApp = new XrmApp(_client);
_xrmApp.OnlineLogin.Login(_xrmUri, _username, _password);

_xrmApp.ThinkTime(1500);
_xrmApp.Navigation.OpenApp(UCIAppName.AppName);


_xrmApp.Navigation.QuickCreate("Deal");
_xrmApp.QuickCreate.SetValue(new LookupItem { Name = "new_field1", Value = "123Dentist" });
_xrmApp.QuickCreate.SetValue(new OptionSet { Name = "new_field2", Value = "Public" });
_xrmApp.QuickCreate.SetValue(new OptionSet { Name = "new_field3", Value = "New Origination" });
_xrmApp.QuickCreate.SetValue("new_field4", "100");
_xrmApp.QuickCreate.SetValue("new_field5", "50");
_xrmApp.QuickCreate.SetValue(new LookupItem { Name = "new_field6", Value = "Bank of America" });
_xrmApp.QuickCreate.SetValue(new BooleanItem { Name = "new_field7", Value = false });

_xrmApp.QuickCreate.Save();

Expected behavior

I would expect this code to populate my fields and save the entity. I have also tried using _xrmApp.Entity instead of QuickCreate with the same results.

Screenshots

Additional context

[rswafford]

Some additional information - I am able to interact with string fields, and optionset fields on a Quick Create form, and I can get a Two-Option field to work by handling it as an OptionSet. Lookups however are still failing with the same error.

[rswafford]

...and one more tidbit from debugging -- Line 591 of SeleniumExtensions.cs shows an exception of "no such element":

OpenQA.Selenium.NoSuchElementException: 'no such element: Unable to locate element: {"method":"xpath","selector":"//div[@role='tabpanel']/parent::*//*[contains(@data-id, 'new_field1.fieldControl-Lookup_new_field1')]"}
  (Session info: chrome=79.0.3945.88)'

Upon reviewing the HTML in Chrome Dev Tools, I suspect it's due to the div[role='tabpanel'] selector, as all of the divs in the tree are set to role='presentation'.

[rswafford]

Further investigation uncovers Bug #620, referenced in Bug #658, that looks to have introduced the role selector. Removing that and recompiling the DLL fixes my issue; however I'm afraid that may re-break original bug with lookups in the header.

[KhoaAN]

@rswafford Are you using the latest EasyRepro version? After updating EasyRepro nuget package to 9.1.0.7606 during end of 2019, i'm facing this same issue. My codes worked with previous version but not this latest version. Not sure if Chrome version matters but i'm on latest Chrome 79.

[rswafford]

Yes I am - see my last comment, I un-did the change in Bug #658 and recompiled it locally, that resolved my issue for Quick Create forms.

[KhoaAN]

If you made changes to the dll, how would you manage your fixes when you upgrade to the new version? Thats my main concern about using custom dll.

[rswafford]

Clone the repo and pull your updates that way, then recompile.

[KhoaAN]

thanks. I'll try to figure out a way to maintain the custom dll with my fixes because the latest version isn't working perfect.

[AngelRodriguez8008]

@rswafford

thanks. I'll try to figure out a way to maintain the custom dll with my fixes because the latest version isn't working perfect.
@u3021007
If you made changes to the dll, how would you manage your fixes when you upgrade to the new version? Thats my main concern about using custom dll.

I have the same problem; I fix the bugs, add features & optimize my custom DLLs. My version work well in my "test system", but I'm not sure about how it works other Environments, I have no time to run all sample tests (locally) & I have just one system (is not for play). Most of my tests are not suitable for run in a "clean trial system", because we have our own customization (I'm not the only one see for example #704). I want to contribute, at least with tests to be corrected, but it is take a lot to time to translate my tests, sometimes is not even possible. Now my version is maybe great, but there is no way to give it back to the community or even try if all “community tests” are working well.
I think we required some kind of D365 Shared Develop/Test Environments (inclusive Build Server) where we can put, run & share tests for our “custom dlls” with improvements, fixes & even features that the “Standard EasyRepro” didn’t support. Where any developer should be able to add his own customization and share his tests succeeded or failures.
I guess it is not too complicate for the Microsoft people. That can accelerate the development & get less frustrated EasyRepro “users”.
We also require some way to add some features that are maybe not in the „Standard EasyRepro“, but are AddIns/Extensions that we can share with others developers. Ex. #170 (#184) some people will like it see discussion #463

[KhoaAN]

@AngelRodriguez8008
I think the sample tests should be ran when they review the pull requests. That would make sure code changes aren't breaking other functionalities.
If you were to run all sample tests to verify your changes, you will have to build the codes to cleanup the data that were created by sample tests. That would be too much work.

[AngelRodriguez8008]

@KhoaAN

"I think the sample tests should be ran when they review the pull requests. That would make sure code changes aren't breaking other functionalities."
That can be done automatically by the Build Server, running all tests in all Environments

If you were to run all sample tests to verify your changes, you will have to build the codes to cleanup the data that were created by sample tests. That would be too much work.
Cleaning Jobs can run weekly in all Environments