Hey Jesper,

Your config seems fine. Do you see any JS errors in your console?

Many thanks

Matt

Just to chime in, I spent some time investigating this bug as I saw it happening on one of my test sites.  It appears to be due to the new version of Newtonsoft JSON.Net.  I was able to start with a pre-7.1.2 install and had success with the widget grid.  Upgrading to 7.1.3 appears to have broken the package in all my testing, though I was having success upgrading to 7.1.2 which uses the new Newtonsoft.JSON assembly redirect.

I find it strange that I've luck with 7.1.2 but not 7.1.3 (or any luck with 7.1.2) but I haven't delved into it much further as I have plenty of other things on my plate.  I just wanted to share the little information I've collected on this.

Aaah, I think this is due to a bug in the core, we'll release 7.1.4 soon but in the mean time try following the instructions in the comments here: http://issues.umbraco.org/issue/U4-4958

Cool, thanks for sharing guys.

Jesper, do you want to give Seb's suggestion a try and see how you get on?

Cheers

Matt

Hi all,

Thanks for chipping in. I've copied all files to /umbraco, bumped the clientdependency version, even cleared the temp\clientdep .... cleared browsercache and running project i debugmode (afaik it disables clientdependency completly) ... but the problem remains exactly the same.

Damn :)

Jesper

ps. I see no script errors

A few more observations .. it happens in all browsers I've tested with IE11, Chrome, Safari 

Ive just testet the buildin datatypes: ContentPicker and MultiNode TreePicker and RTE's image picker -  all works as supposed. 

With the Widget grid it seems like two problems:

1) The dialog works fine first time but returns nothing.

2) Second time the dialog fails after the dialogService.treePicker(angular.extend({ .. as the call back never happends ..

Argh - have to revert to Multinode Treepicker for now

best
Jesper 

Hey Jesper,

I've just had a quick look. I don't have a fix so far, but I do believe it is a core issue as if you create a multi node tree picker data type, and choose a start node for it, you'll notice that that dialog produces the same behavior (first click doesn't register, and the second one screws the UI up).

It looks like the first click does save the value, it just doesn't update the UI (ie, if you save, and reload, it will have saved the selected node id).

I'll see what else I can find though.

Cheers

Matt

Ok, scratch that, turning debug mode on and applying sebs patch, does fix it for the built in dialogs, however WG is still screwed.

@seb any details on what was changed in those files to fix it? Does this mean a change will need to be made to WG? (I would hope not as it did work before, so something in core has clearly changed unexpectedly)

Cheers

Matt

Hmmm ..

Debug mode on - check

Apply patch - check

Client Dependency version number - bumped

Restart in VS

Clear all caching in IE, Chrome - check

===============================

Result? Nothing changed - same problem.

Also no value stored in WG

Found this in the log - which is very dark talk to me :)

=== Pre-bind state information ===

LOG: DisplayName = Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed

 (Fully-specified)

LOG: Appbase = file:///C:/REPOS/Sweb/Umbraco Test 1/Umbraco test packages/Umbraco test packages/

LOG: Initial PrivatePath = C:\REPOS\Sweb\Umbraco Test 1\Umbraco test packages\Umbraco test packages\bin

Calling assembly : (Unknown).

===

LOG: This is an inspection only bind.

LOG: Using application configuration file: C:\REPOS\Sweb\Umbraco Test 1\Umbraco test packages\Umbraco test packages\web.config

LOG: Using host configuration file: C:\Users\jesperordrup\Documents\IISExpress\config\aspnet.config

LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.

LOG: Attempting download of new URL file:///C:/Users/jesperordrup/AppData/Local/Temp/Temporary ASP.NET Files/root/5717c8ca/5ded8b30/TempDomain9b8b14dd-c512-47b7-877d-41da313a20a5/Newtonsoft.Json.DLL.

LOG: Attempting download of new URL file:///C:/Users/jesperordrup/AppData/Local/Temp/Temporary ASP.NET Files/root/5717c8ca/5ded8b30/TempDomain9b8b14dd-c512-47b7-877d-41da313a20a5/Newtonsoft.Json/Newtonsoft.Json.DLL.

LOG: Attempting download of new URL file:///C:/REPOS/Sweb/Umbraco Test 1/Umbraco test packages/Umbraco test packages/bin/Newtonsoft.Json.DLL.

WRN: Comparing the assembly name resulted in the mismatch: Major Version

ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

2014-05-22 21:22:03,770 [22] ERROR Umbraco.Core.Packaging.PackageBinaryInspector - [Thread 10] An error occurred scanning package assemblies

System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

File name: 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'

   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)

   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)

   at System.Reflection.Assembly.ReflectionOnlyLoad(String assemblyString)

   at Umbraco.Core.Packaging.PackageBinaryInspector.PerformScan[T](String dllPath, String[]& errorReport)

I'm now seeing this issue even with the v7.1.4 js files :-(

This is the change that broke the dialogs in v7.1.3 and I think this commit is what fixed it for the core editors.

Of course, this would be a nasty braking change if all non-core requests for dialog services needed to be updated....

Thanks Jeavon .. I just downgraded a copy my project:

Install-Package umbracoCms -version 7.1.2
(L for no to all overrides)

Note: I have no idea if this is "the way" to downgrade - havent done that before. Anyone?

After that (and a scary install dialog that made me think that all is gone) all my content was there. And it works - Widget Grid works exactly as supposed.

@seb - do you need me to update any bug reports with further info or do you have what you need?

/Jesper

Ok, so I think I can see what the issue is (not tested, just looking at the comits Jeovan referenced). I think it's because a parent scope is being passed to the dialog services which now gets destroyed when the dialog is closed, which it didn't used to be. I'll have to see if it's an issue to not pass the scope in, but yea, this is a pretty significant breaking change if that is the case.

Matt

Ok, checked out my theory, and I am right, it is because the scope gets destroyed. I commented out line 86 dialogConfig.scope = scope; in App_Plugins/WidgetGrid/js/widgetGrid.js and it all seems to work fine.

Do you want to give that a try?

Matt

@seb maybe it's worth adding something that detects if a scope is passed in, if so, assume the dev is going to handle the scopes lifecycle and only if they don't pass one in, create a new one, and only destroy that one on close?

Matt

(PS Granted I don't know all the reasons for the change however)

YES YES YES YES YES (it works, Matt)

But if all non-core requests for dialog services needed to be updated then I'm still sh*t out of luck. Havent seen any other problems. *)

best
Jesper 

*) Archetype doesnt work with the image cropper but that could be something else.

Confirmed for me, commenting that line fixes it! However I've plenty of other editors, e.g. Url Picker which also use dialogs that are still broken, ideally @Matts suggestion might work, otherwise I guess it's just going to be a braking change.

Thanks Matt!

p.s. I have fixed Url Picker now by also removing the $scope parameter

@Jeavon yup, if it stays like it is, it's going to require anyone who opens a modal to change how they do it (if they've used the old Umbraco code as a basis for how to do it and thus passing a scope in) so I agree, some kind of check should be added to prevent everyone from having to update.

@jeavon I guess the problem is if anyone who launches a dialog actually makes use of the passed in scope within the dialog window itself then removing the scope param isn't going to fix it. I guess what I mean is it's not just a sweeping statement we can make (remove the $scope param).

Matt

@Matt, yes understood!

Hi Seb,

Thanks for investigating. Totally happy with everything and no need to apologize to me. This is how things work and what takes the focus and makes me happy is how you react when shit happens :-)

best
Jesper 

Awesome Seb, the other editor that I saw the issue in is Url picker, but it can be easily fixed for next release

@Jeavon aha, I tried the multi URL picker, thought you were referring to that one. But seeing as though this URL picker is not on Our hopefully it's not widely used yet. I'll shoot them an email.

@Jeavon - did you say you fixed this in URL Picker? Mind shooting over a quick PR or just pasting the update here? We'll get it merged in ASAP!

Thanks!

@Tom, yup, I will do that tomorrow

Hi guys,

Here's the full details and background:

• For whatever reason in the core it was decided that passing in a $scope to the dialog service to then be assigned as the $scope in the dialog was a good idea - it is not really a good idea.
  • Generally speaking we should not be passing around scopes, especially not if the code you are passing it to is going to modify the scope - which the dialogService was doing
• The only reason there was an option to pass in a scope to the dialogService was so that you could access data on the existing scope in the scope of your dialog - but there are 2 other (better) ways to pass data to your dialog:
  • dialogOptions - any option you pass to the dialogService will be available in the $scope.dialogOptions object in your dialog
  • dialogData - this will be deprecated - if you specify an option called dialogData when passed to the dialogService, it will be assigned directly to the dialog scope: $scope.dialogData - it will be deprecated because the dialogOptions method provides more meta data for you to work with in your dialog

The change that was made in 7.1.3 was because we had a memory leak. When a $scope was not passed to the dialogService (which is very often) a new one was manually created on top of the $rootScope and was never destroyed. It is a bug that the passed in $scope was being destroyed and the reason was because the navigationService was also manually creating a new scope on top of the $rootScope, passing it to dialogService and then never destroying it either - it was thought that this was the only place that a $scope was actually being passed to the dialogService.

Moving forward:

• Do not pass in a $scope object to the dialogService
• We will always destroy the $scope in the dialogService - but we will not destroy the scope passed into it, instead we create a child of the $scope passed in to it - this will solve this issue, but you just shouldn't pass your own scope in anyways and use dialogOptions to pass data to your dialog.
• If you ever do something like $rootScope.new() you must ensure that you destroy it manually, otherwise it will exists for the lifetime of the app in memory

Hope that all makes sense

PS... I will ensure we get the API docs updated to reflect that a scope should not be passed in.

I'm on 7.1.4 and I'm not able to add elements to WG in the backend.

After commenting out line 86 dialogConfig.scope = scope; in App_Plugins/WidgetGrid/js/widgetGrid.js (as suggested by Matt) and changing the clientDependency version in Config/clientDependency.config it is working for me.

is working on a reply...