load_from_url on macOs completely kills the application

[gwynnbleiidd]

Bug Reports

1. SketchUp/LayOut Version:2021
2. OS Platform: macOS

Greetings, I am confronted with a confusing situation. The plugin described below completely kills the application. If you run it in Ruby console either as a plugin or through a third-party console plugin like Ruby Console+.

In the example you can see that there should at least be a loading progress. But when called, everything works fine until you click the download button. Tried downloading the model from another hosting, the situation is the same. When you click on the download button, the program dies.

Checked the rights to the program folders, plugins and temporary directories. Everything is fine there, nothing suspicious noticed.

On Windows, plugin works fine no complaints. code here - https://gist.github.com/gwynnbleiidd/22db5438094b4a19cee1e8455d788d6c

[DanRathbun]

Do you see the test messages in the Ruby console ? Ie ... "Test URL: #{url}" (with the URL inserted) ... and from the LoadHandler constructor the message ... "Attempting download of model: #{id}" (with the model id inserted) ?

[gwynnbleiidd]

Do you see the test messages in the Ruby console ? Ie ... "Test URL: #{url}" (with the URL inserted) ... and from the LoadHandler constructor the message ... "Attempting download of model: #{id}" (with the model id inserted) ?

only Test URL

after program freeze

[thomthom]

Thank you for providing a complete example to repro this. I see this on mac with SU2021.0, SU2020 and SU2019 (didn't try going further back). SU2021.0 Windows worked fine.

[sketchupbot]

Logged as: SKEXT-3058

[thomthom]

This happens specifically on macOS when called from an UI::HtmlDialog's action callback.

Potential workaround for affected versions of SketchUp:

Defer the logic that calls .load_from_url using a timer.

module Example

  def self.open_dialog
    @dialog = UI::HtmlDialog.new
    @dialog.add_action_callback("say") { |action_context, url|
      self.load_component_deferred(url)
    }
    @dialog.set_file("path/to/file.html")
    @dialog.show
  end

  def load_component_deferred
    # The timer delay is enough to avoid .load_from_url from deadlocking.
    UI.start_timer(0, false) do
      self.load_component(url)
    end
  end

  def self.load_component(url)
    model = Sketchup.active_model
    definition = model.definitions.load_from_url(url)
    # ...
  end

end

[DanRathbun]

So the fact that a LoadHandler is involved is not at issue ?

[gwynnbleiidd]

Thank you, that helped. I put a delay of 1 and it started working. Now some problems with model.place_component(definition). The impression is that the application is defocused and you need to click again in the sketchup window to see the component near the mouse cursor.

[DanRathbun]

_Now some problems with model.place_component(definition)._

Please begin a new issue or a new topic in the public forum (when the topic changes.)

The impression is that the application is defocused and you need to click again in the SketchUp window to see the component near the mouse cursor.

See open feature request:

• Sketchup module method to return focus to the modeling window (493)

  UPDATE: Implemented with release 2021.1 as Sketchup::focus

[DanRathbun]

@gwynnbleiidd Please do not close open issues that are logged as bugs. The SketchUp bot will close them after they have been fixed following a future release.

[honkinberry]

I would like to primarily state that this has been an issue with HtmlDialog since 2017. I imagine it is related to the similar Net::HTTP issue. It's painfully obvious that there is little emphasis on making the Mac version as stable as Windows. Unfortunately, the combination in being able to use either load_from_url or Net::HTTP in a synchronous fashion is that the Mac version is quite hobbled in terms of downloading anything. In a perverse sense, we're slightly prepared for this, in that the issues with WebDialog forced us to re-engineer all dialog boxes to be modeless. So since all of our dialogs are already needlessly modeless, we have some workarounds. But any chance at utilizing HtmlDialog to restore some modal dialogs is completely out of the question because of this.

To me the more pressing issue is the loss of Net::HTTP, as that would be my preferred workaround to this issue. But losing them both on Mac really pushes us up against a wall. I've got thousands of user of our plugin, and I'm seriously considering dropping support for the Mac version, because we can't download resources in a viable manner. Frankly, I wish Trimble would just make that decision for us -- just stop pretending there is a Mac version of SketchUp, unless you are going to address some of these critical bugs that go back 5+ years.