[OPEN] [#413] // Remark in javascript in a DirectEvent Loaded UserControl causes SyntaxError: missing } after property list

[michaeld]

This code inside ascx control that is Rendered during a DirectEvent

<ext:Container ID="Cont" runat="server" Flex="1">
    <HtmlBin>
        <script type="text/javascript">
            var Map = {
                map: function (center) {
                    var mapOptions = {
                        center: center //new google.maps.LatLng(this.center[0], this.center[1])
                    };
                }
            };
    </script>
    </HtmlBin>
    <Items>
        <ext:Label ID="Label1" runat="server" Html="Inner" />
    </Items>
</ext:Container>

I'm assuming the issue is the exclusion of a newline. It does not occur if wrapped in /* */

[Vladimir]

When control is rendered dynamically (during direct event) then generated javascript code is converted to single line to be returned in ajax request body
Therefore single comments cannot be used in javascript

I don't see yet how we can automatically resolve it. At this moment you have to use /**/ comments

[michaeld]

When control is rendered dynamically (during direct event) then generated javascript code is converted to single line to be returned in ajax request body
Therefore single comments cannot be used in javascript

I don't see yet how we can automatically resolve it. At this moment you have to use /**/ comments

Just noting the issue and the same resolution was found as well. However, I do not understand why these have to be converted to a single when SourceFormatting=true. It really makes debugging client-side Responses quite painful without breakpoints. Is there any reason you cannot maintain the existing newlines in htmlbin sections with this simple conversion?

http://stackoverflow.com/questions/42068/how-do-i-handle-newlines-in-json

[Vladimir]

Generated javascript (from ajax request) is executed in 'eval' method
Try to run the following code

eval("alert('one');//sometext\\n\\n alert('two')")

You will see only first alert

[michaeld]

Generated javascript (from ajax request) is executed in 'eval' method
Try to run the following code

eval("alert('one');//sometext\\n\\n alert('two')")

You will see only first alert

Valid point, do you mind sharing where I can find the code that removes the newlines? I'd still like to have newlines in my eval'd code so I can console.break() on lines. Somewhere these \n's are being stripped from the ITemplate HtmlBin, and I'd like to look under the hood. It seems to me remarks could be removed too with a little smarts.

[Daniil]

We discovered that this works:

eval("alert('one');//sometext\n\n alert('two')")

Also the following works during a DirectEvent.

X.Js.AddScript("alert('one');//sometext\n alert('two');");

So, the issue happens while rendering HTML. It is done in Core\BaseControl\Lifecycle.cs, line #1110:

string[] lines = html.Split(new string[] { "\r\n", "\n", "\r", "\t" }, StringSplitOptions.RemoveEmptyEntries);

At least, it was done to reduce traffic and improve formatting of the output. Maybe, something else. I don't know for 100%. Unfortunately, the issue with "//" arises with that approach.

So, from one side we have "reduce traffic" and "better formatting", and "break due to JavaScript" from another side.

Though, as far as we can remember you are the first one who caught it.

Anyway, we should review it, at least, for v3.
https://github.com/extnet/Ext.NET/issues/413

Thank you for the request.

[michaeld]

At least, it was done to reduce traffic and improve formatting of the output. Maybe, something else. I don't know for 100%. Unfortunately, the issue with "//" arises with that approach.

Totally understandable. Small footprints make sense. However, so does the need for debugging in debug cases. Just like in SourceFormatting setting in ResourceManager, it's important to be able. So beyond the topic of this bug which is easy to work around, I'm far more interested to find out if you intend to allow us to keep our formatting in the htmlbins of client-side evals. You didn't mention if you'll be able to support this in the future.

So, from one side we have "reduce traffic" and "better formatting", and "break due to JavaScript" from another side.

Yes, the option to choose would be lovely.

[Daniil]

So beyond the topic of this bug which is easy to work around, I'm far more interested to find out if you intend to allow us to keep our formatting in the htmlbins of client-side evals. You didn't mention if you'll be able to support this in the future.

At the first glance we don't see a clear way to achieve that. Hopefully, there is a way.

[michaeld]

So I found there is a case where the eval'd script contains proper newlines. The case in which they do is when I have newlines in the handler of a listener for a control.

So there is a way to get the newlines.
Example:

            <TriggerClick Handler="
                switch(index) {
                case 0: ZRScope.remove();break;
                case 1: ZRScope.select(#{Ctl1});break;
                }" />

... constructs this response:

...
,triggerclick:{fn:function(item,trigger,index,tag,e){\r\n\t\t\t\tswitch(index) {\r\n\t\t\t\tcase 0: ZRScope.remove();break;\r\n\t\t\t\tcase 1: ZRScope.select(App.ctl00_cp_id48514cc72cea7578_id2a0eed021ddb6e68_Ctl1);break;\r\n\t\t\t\t}}}

which invokes a VM5401 with:

...
triggerclick:{fn:function(item,trigger,index,tag,e){
                switch(index) {
                case 0: ZRScope.remove();break;
                case 1: ZRScope.select(App.ctl00_cp_id12a669fc700a792f_idda3d5f32b658421f_Ctl1);break;
                }}},...

Clearly there is a difference between the preprocessing happening in an HtmlBin that is different than a Listener.Handler so I think there are clues this isn't such an unattainable goal. Moreover, I hope it means we can enforce SourceFormatting only when true on DirectEvent/Method responses.

[Daniil]

Yes, a good catch. Thank you for the notes!

Yes, the goal should be attainable.