Paste In URL Field Not Working

[gitgeoff]

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like that [x])
• Use Preview tab to see how your issue will actually look like

WARNING

All invalid issues will be rejected!!

---

Before going further

• If your problem is a bug with youtube-dl or a request for new site support please report it here

• Make sure you are using the latest yt-dlg version (Click the Settings icon and then About to view the current version)

• Make sure you are using the latest youtube-dl version (Click the Settings icon and then Update to update to the latest youtube-dl version)

• Make sure you searched the bugtracker for similar issues including closed ones

• Make sure to read the FAQs file

  • I think my problem is NOT with youtube-dl
  • I've verified and i assure that I'm running yt-dlg 1.X.Y
  • I assure that i am using the latest version of youtube-dl
  • Searched bugtracker
  • I've read the FAQs file

---

What is the purpose of your issue?

• Bug report
• Feature request (request for a new functionality)
• Question
• Other

Please remove any sections between (---) if they are not related to your issue

---

Bug report

What operating system do you use ?

Mac Ventura 13.0

List of actions to perform to reproduce the problem:

1. Open yt-dlg
2. Attempt to paste any text into the URL field using either Command-V or the Context (right click) menu Paste option

What is the expected behaviour ?

I expected to be able to paste a URL into the field instead of typing it.

What happens instead ?

Nothing. The field is unresponsive to a paste action. I can successfully type a URL and download a video, but not paste in the URL of interest.

See above description of issue. I cannot paste a URL into the top field. Manually typing a URL results in a successful download as expected.

Fresh install today using "pip3 install yt-dlg". The installer reported "Successfully installed altgraph-0.17.3 macholib-1.16.2 numpy-1.24.2 pillow-9.4.0 polib-1.1.1 pyinstaller-5.6.2 pyinstaller-hooks-contrib-2023.0 pypubsub-4.0.3 six-1.16.0 wxPython-4.2.0 yt-dlg-1.8.4". I am running all default settings.

I am executing the application by issuing "yt-dlg" in the terminal. Everything seems to run normally although the terminal output does display this warning after startup:
MacBook-Air-5:~ username$ yt-dlg
2023-02-19 13:13:32.141 Python[23608:1507865] Warning: Expected min height of view: (<NSPopoverTouchBarItemButton: 0x7fda008b3320>) to be less than or equal to 30 but got a height of 32.000000. This error will be logged once per view in violation.

I have searched all open and closed issues for the word "paste" and there are no hits. I have searched the FAQ for the word "paste" and there are no hits.

[Oleksis Fraga Menéndez]

The development on macOS need more tests. I make the test for macOS Monterey on a Virtual Machine

Any advice or more info how fix this behaviour in macOS are welcome 🙏🏾

[gitgeoff]

*** Edited to fix format of the multi-line code snippets.

I don't now anything about wxPython, but from looking at the docs for wxPython 4.2.0 and the code for mainframe.py, I am thinking that the problem may be in the event handler.
Reading this: https://docs.wxpython.org/wx.TextCtrl.html#phoenix-title-event-handling, it says that an ID_PASTE event is handled automatically by default event handlers. However, the setup of the TextCtrl explicitly binds a custom event handler to two events, EVT_TEXT_PASTE, and EVT_MIDDLE_DOWN (lines 1102-1104 in mainframe.py). According to https://docs.wxpython.org/wx.ClipboardTextEvent.html, those events are only generated by TextCtrl on wxGTK and wxOSX (linux and mac I presume), and this difference may be why this has not been noticed if a majority of devs and users are on Windows.

Since that handler _on_urllist_edit (lines 1353-1366) hands both events (from comments, it appears that is Command-V for EVT_TEXT_PASTE, and right click menu for EVT_MIDDLE_DOWN)over to _paste_from_clipboard, and both of those fail on Mac, I'd suspect that's where the problem will lie.

_paste_from_clipboard (lines 1331-1351) seems odd as it seems to assume that if the ClipBoard is already opened, no action can/should happen, and returns from the method without action:

     if wx.TheClipboard.IsOpened():
          return

     if wx.TheClipboard.Open():

On the other hand, a code example I'm seeing on StackExchange (reader beware) shows logic that checks if the clipboard is already open, and if not, opens it before proceeding:

     if not wx.TheClipboard.IsOpened(): wx.TheClipboard.Open()
          do = wx.TextDataObject()
          success = wx.TheClipboard.GetData(do)
          if success:
               return do.GetText()
          return ""

I'm guessing that the clipboard is showing up as open and then the code silently ignores the request, I'd recommend changing lines 1336-1339 to:

        if not wx.TheClipboard.IsOpened():
            wx.TheClipboard.Open()

        if wx.TheClipboard.IsOpened():

Note that all three non-whitespace lines are altered. The original code would always return with no operation if the clipboard was already opened. The suggested code opens the clipboard if it is not already, then confirms that it is opened before proceeding. That would still fail silently if the clipboard failed to open for some reason, but seems to make more sense. I would test this and submit a pull request but don't have a development environment and can't find a way to edit the mainframe.py file locally from my install.

[Oleksis Fraga Menéndez]

Can clone this repository and follow the steps for macOS Monterey . Let us know how the workflow on macOS

[gitgeoff]

It turns out there were two issues. Even after implementing the fix I recommend above for the logic of testing the clipboard status, there was another issue described in wxWidgets/Phoenix#2042, where wx.DF_TEXT does not work on MacOS, and wx.DF_UNICODETEXT is recommended as a straight replacement. See also wxWidgets/Phoenix#2047

I've created a pull request with a fix for both issues, which restore the expected behavior in my local instance.