bug w/ image drag-in

Welcome! Forums TypeMetal Support bug w/ image drag-in

This topic contains 16 replies, has 2 voices, and was last updated by   2 years, 7 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)

  • Author


  • #522

    Martin Doudoroff

    I hope this reproduces for you, because it’s currently repeatable for me.

    1. close all TypeMetal documents and quit TypeMetal
    2. launch TypeMetal
    3. in the blank default document enter type “para 1”, hit return, type “para 2”
    4. COMMAND+s and save to Desktop as “test.html”
    5. open a finder window and drag a jpg from the Desktop between “para1” and “para2” (if no jpg on your Desktop, copy one there first)

    You should find that the filename is represented correctly in the src attribute, but the image is broken otherwise.


    It appears to me that this is one of those permissions problems. When you save the file to the Desktop, the app doesn’t get permission to save the file there, and then when you drag an image in from there, stuff goes haywire.


    Troy Stephens


    Thanks, Martin! I had noticed this myself and was just debugging it moments ago!

    For some odd reason, the initial request to load the just-added image sometimes comes in from WebKit as an “applewebdata://” URL. Normally it’s a “file://” URL (annotated with Sandbox permission data), and in those cases TypeMetal successfully retains authorization for the duration the referencing HTML file is open. I need to figure out what I can do in the “applewebdata://” case.

    A quick workaround is to close the HTML file and reopen it. TypeMetal will prompt you to grant read permission for an enclosing directory (if you haven’t previously), and the image, and all subsequently added images from the same file tree, should then load fine.

    Fortunately this only seems to occur when you’re working in a new tree of the filesystem where you haven’t used TypeMetal to open and edit files before (and thus haven’t granted TypeMetal folder permissions). Once you’ve worked in a particular file system area, you shouldn’t have to do the close-and-reopen trick for files in that subtree again (especially if you granted permission for a suitable root folder that encompasses everything the project’s HTML files reference — e.g. “~/Projects/ClientSite” — as advised under “Answering, and Avoiding, Repeated Requests” here).

    Sorry for the inconvenience! I hope to have a fix for this soon.


    Troy Stephens


    Oh, and: The incorrect indication of “0x0 pixels” is a consequence of the image load failing. I’ll make sure it works correctly again once I’ve fixed that.

    Thanks for posting the helpful screen grabs, by the way! I’m sorry you have to host the images somewhere yourself! — I’m going to look into easy image attachment for forum posts.


    Troy Stephens


    Ah, fascinatingly squirrely bug due to a WebKit resource URL handling behavior I wasn’t aware of. Only happens in a new HTML file after you’ve Saved it in a permanent location, until you close and reopen it. If I tickle a reload from the new HTML file after saving to it, the dragged-in image successfully loads, because it clears the “baseURL==nil” state that got stuck in WebKit’s state when the new, empty document was created. I need to make sure the reload OK to do, and won’t cause unwanted side effects (such as bugging you to authorize access to an enclosing folder). But I think I’m close to having a handle on this.


    Troy Stephens


    Hi Martin,

    A fix for this is finally out, in TypeMetal 1.1.2!

    I hope you’re still enjoying using TypeMetal! Please let me know if I can be of help with any other issues!

    Thanks & Regards,

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.