Drag 3D Warehouse link into SketchUp

Can we get back the support for dragging the download link from 3D Warehouse in an external browser directly into SketchUp to load components? Until some year ago this was possible and there was no need to use the internal browser or Component inspector.

Then from one day to the next this topped working. I suspect due to a change in the warehouse, but it could also be a silent browser update (God, I hate silent updates). The components dragged into SketchUp this way got odd names like “attachment; filename=Untitled; filename_=utf-8’'Untitled#1” that Dynamic Components couldn’t handle, which may be why the useful behavior was sadly removed (I’d rather have the bugged DCs removed).

External browser are superior in every ways over the internal one as they support tabs, bookmarks, copying/pasting full addresses, minimize to taskbar, not closing once you place a component and so much more.

Yes, I noticed it too, a bug was filed a while back, and I’ll update in another thread in this forum when we push the fix.

1 Like

Is this a reply to my comment or some other comment?

In direct response to this. For Warehouse, it’s issue 10877.

1 Like

The model information page in 3D Warehouse seems to have been updated recently but this still doesn’t work. In fact it is even further from working as the downloads “links” are no longer actual links and can’t be dragged at all. In my previous video the links could be dragged but SketchUp no longer recognized them when dropped.

Do the people who work on the EW front end know this is a logged issue?

I would be very happy if this was fixed. The only practical way to use the EW that I know of is to open 20 or so search results in new tabs, based on how well their thumbnails look, and then go through the tabs and eliminate all that are too badly drawn or to large, based on the preview image and model statistics. This workflow requires a proper standalone browser with tabs. Placing models from the external browser was so much more connivent than having to temporarily save them somewhere, browse to that location, and drag them into SketchUp from there.

Btw, having “fake” links (not actual a elements) prevents middle mouse button clicks, right click > Copy link address and more from working. It’s a bit annoying with elements that appears to be of one type but doesn’t function that way.

I think that this may be an intended change.

I seem to remember questions here in the forum, which I thought were innocent at the time, about “scraping” the 3DW download menu for model download links. The quester indicated it was for an extension for downloading their specific models. So I helped answer their questions.

It now occurs to me that this activity could be not so innocent. Ie, abused to set up a mirror warehouse that draws model files from Trimble’s 3DW.

So now it appears that the information used to download files from 3DW has been purposefully obfuscated. Because of this I’m not comfortable further discussing the specifics of how.

1 Like

It’s possibly behind an internal API.

Another innocent reason could be that the new 3DWH has been developed more like a web app. “JavaScript links” have been common for long time in web development to catch the click event and handle it e.g. within the page (single page app). But some websites still keep URLs in the href (instead of href="#") to keep the semantics and compatibility when JS is disabled. So it could be added back…

I wonder, if the HTML5 drag&drop API allow to pass arbitrary text content with a dragged element to another app, one could pass a skp URL that can be dragged into SketchUp.

1 Like

Never thought of that but is a very reasonable explanation.

I’ve suspected the change was because of a bug in Dynamic Components. When dragging and dropping links into SketchUp, components were cryptically named. I think the name was a part of the URl or a JSON string or some other odd thing. Anyhow, the name seamed to trigger a javascript error in Dynamic Components. Rather than just accepting the DC plugin can’t handle components loaded this way and live with it because DC is totally broken anyway, I’m suspecting this way to download models were removed as a workaround. This is however just speculations. I’d love to hear what actually happened.

Maybe the download link could when dragged instead resemble the link to the information page itself, and SketchUp could internally parse that link and fetch the right model version? This would however require a change in the SketchUp core, and would only affect new mayor versions. Since the behavior changed from one day to the next, with no SketchUp update, I’d hope it could be resolved the same way.

We would hope that holding and dragging would fire a separate event that could have it’s own behavior form a normal click.

The internal SketchUp browser frames see a different user agent string than a standalone browser instance with the 3DW loaded, so the behavior could change because the server could server different pages.

I just was reading up on the registry settings for the MS WebBrowser control and there is a setting that will enable multiple tabs. I switched it on by adding the correct attribute in SU2016, then restarted SketchUp and tried it out in an internal 3DW window. It did enable the right click context “Open in new tab” item, but it opened the link in an external instance of full MSIE. And to make things worse, the pages did not work well, (missing images, etc.) and the Download button did not work at all.

So that line of interest is a bust (besides v2016 going to beyond EOL this coming November.)

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.