locked
Issue with data URI in latest Chrome RRS feed

  • Question

  • For this reason, in Chrome, my images suddenly stopped loading.

    Please someone from the Lightswitch Team take a look at this.


    Regards, Christopher Maduro


    Friday, September 12, 2014 5:24 PM

Answers

  • It's a bug in the 37 build. It's reported and will be fixed (I hope). If you put /jpeg inside the binary string it works though.

    Sven Elm

    • Proposed as answer by ChrisCookDev Sunday, September 21, 2014 10:40 PM
    • Marked as answer by Angie Xu Monday, September 29, 2014 7:17 AM
    Friday, September 12, 2014 5:48 PM

All replies

  • It's a bug in the 37 build. It's reported and will be fixed (I hope). If you put /jpeg inside the binary string it works though.

    Sven Elm

    • Proposed as answer by ChrisCookDev Sunday, September 21, 2014 10:40 PM
    • Marked as answer by Angie Xu Monday, September 29, 2014 7:17 AM
    Friday, September 12, 2014 5:48 PM
  • The problem I have is that my image is coming as a related entity from another datasource. So it is being loaded after postRender is called. And I cannot even seem to fix it by data binding. Could I add an event listener to the img src propert? How would I do this?

    Regards, Christopher Maduro



    Friday, September 12, 2014 5:51 PM
  • It's a bug in the 37 build. It's reported and will be fixed (I hope). If you put /jpeg inside the binary string it works though.

    Sven Elm

    What do you mean, Sven? where?

    I can confirm this is happening with Chrome 37.0.2062.120 m version.

    Even LS HTML native button icons are not loading at all (like Add New, etc.), making the application unusable.


    Nicolás Lope de Barrios
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.

    Friday, September 12, 2014 8:39 PM
  • It should not affect the icons because they are not base64 encoded. Strange..... I only confirmed, what was missing in the binary string editing the html (f12) in chrome. You cannot fix it prior the encoding I think. We have to wait for Google to fix it or not use Chrome meantime.

    Sven Elm

    Friday, September 12, 2014 9:09 PM
  • It's a pain, I know. Check out the comments in Chromium 

    Nicolás Lope de Barrios
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.

    Friday, September 12, 2014 9:12 PM
  • As a temporary fix you can make the following small modification to your msls-?.?.?.js (in our case msls-2.5.0.js): -

    Change the following code in the _updateView function: -

    if (!!type && (type.id === ":Binary" || type.id === msls_builtIn_extensionName + ":Image")) {
        dataUrl = "data:image;base64," + me.src;
    }
    

    To the following: -

    if (!!type && (type.id === ":Binary" || type.id === msls_builtIn_extensionName + ":Image")) {
        dataUrl = "data:image/jpeg;base64," + me.src;
    }

    In addition to this small change you'll need to modify your default.htm file to reference the msls-?.?.?.js file rather than the msls-?.?.?.min.js minified version e.g change the following: -

    <script type="text/javascript" src="Scripts/msls-2.5.0.min.js"></script>

    To the following: -

    <script type="text/javascript" src="Scripts/msls-2.5.0.js"></script>

    Alternatively, if you don't want to hack the msls-?.?.?.js file you could address this problem in each of your image control's postRender functions using the following code: -

    myapp.BrowseClientSiteDocuments.Thumbnail_postRender = function (element, contentItem) {
        var imageInner = $(element).find(".msls-image-inner")[0];
        imageInner.src = imageInner.src.replace("image", "image/jpeg");
    };
    

    Hope this helps,

    Chris

    Saturday, September 13, 2014 3:47 PM
  • Rather than modifying the msls-?.?.?.js file, I'd recommend simply cutting and pasting the _updateView function into a new .js file (e.g. customui.js) and adding an include for that file in your HTML client's default.htm.  If you add the include for the new file after the msls.?.?.?.js file it will override the behaviour specified in the original.

    This will leave the default LightSwitch inclusions in place and leave them in a better position to be upgraded by NuGet or when loaded after a VS update at a later date.  Always better to extend/override than to mess about with core infrastructure.


    Sunday, September 14, 2014 8:49 AM
  • Good point Solitaire but msls controls are in anonymous self executing functions so they often cannot be overridden externally without changing msls.js. It would be nice if they would expose msls so the objects could be extended without altering the script
    Sunday, September 14, 2014 1:15 PM
  • I had this on my backlog, someone noticed the broken imaged last week and I ment to investigate today. Glad the issue is already discovered and reported!

    If I append the /jpeg to the mime type, but the image data is png/jpg/..., will that work? Has anyone tested this workaround on all browsers with different types of images?

    Thanks!


    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Monday, September 15, 2014 5:26 PM
  • Hi Jan,

    When I initially investigated the issue on our projects I discovered that Chrome didn't seem to be utilising the mime type value - just checking for a valid entry.  As a result, you should be able to substitute the jpeg with whichever image type takes your fancy png, gif ...

    HTH

    Monday, September 15, 2014 6:17 PM
  • Yes appending /jpeg will work no matter what image data is present. The responsible Chromium coder stated that he will revert breaking changes. In the mean time I am currently replacing all images with custom control.

       var img = new Image(75, 100);
        //Instantly loaded place holder image for no data
        img.src = "data:image/jpeg;base64,%2F...FZ";
        $(element).append(img);
    //Storing image in related entity loads text data fast     
    contentItem.data.getPicture().then(function (r) { 
            img.src = "data:image/jpeg;base64," + r.Image;
        });

    Regards, Christopher Maduro


    Monday, September 15, 2014 6:59 PM
  • Thanks for letting us know about this. We will also look into it on our end to make sure LightSwitch is doing the right thing going forward as well.


    Patrick Baker (Visual Studio LightSwitch Test Lead)

    Monday, September 15, 2014 7:30 PM
    Moderator
  • Alternatively, if you don't want to hack the msls-?.?.?.js file you could address this problem in each of your image control's postRender functions using the following code: -

    myapp.BrowseClientSiteDocuments.Thumbnail_postRender = function (element, contentItem) {
        var imageInner = $(element).find(".msls-image-inner")[0];
        imageInner.src = imageInner.src.replace("image", "image/jpeg");
    };


    Hey Chris,

    well in the event that MS fixes this issue on their side, you'll have to undo this fix or end up with 'image/jpeg/jpeg' ;)


    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Wednesday, October 1, 2014 9:02 PM
  • Hi folks,

    Google Chrome reached version 38.x and the issue is not fixed. I just tested it with an App retrieving binary jpg files from the database.

    Does anybody have a reliable yet simple solution? Also, we haven't had any news since Patrick Baker from the LS team said they will look into it.

    On a side note, I don't understand why this post is marked as answered. Maybe because the root of the problem was found?

    Regards.


    Nicolás Lope de Barrios
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.


    Tuesday, November 4, 2014 1:55 PM
  • From my reading of the issue, it looks like it has been fixed and will be available in version 39.


    Patrick Baker (Visual Studio Senior Development Lead)

    Wednesday, November 5, 2014 8:06 PM
    Moderator
  • From my reading of the issue, it looks like it has been fixed and will be available in version 39.


    Patrick Baker (Visual Studio Senior Development Lead)

    Thank you, Patrick.

    Nicolás Lope de Barrios
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.

    Thursday, November 6, 2014 3:02 PM
  • Thanks for the update on this issue.

    Patrick, could you please address Microsoft's reluctance to give us any information on the future of Lightswitch.  Any type of Roadmap would be better then what we have now.  I'm sure you've seen this post:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/f4aa5b50-2fb5-46da-9cad-6771c8314f01/can-we-have-another-town-hall-and-detailed-product-road-map-please?forum=lightswitch

    By the way, that post is hard to read now because of all the indentation due to so many replies.

    Sorry I'm hijacking this post but we need answers.

    Thanks,

    Dave

    Thursday, November 6, 2014 5:53 PM
  • Update: I can no longer reproduce the issue in Chrome version 39.0.2171.71 m.
    Tuesday, December 2, 2014 1:40 AM
  • Hi,

    It's fixed in the latest update (39).


    Sven Elm

    Tuesday, December 2, 2014 6:39 AM