Long URL is truncated
When the following URL is passed to BrowserChooser2:
http://links.mountaingoatsoftware.com/u/click?_t=63a7abd958e4476e981f7dfae6360e05&_m=b290e0f87fe44df3a8d81f5945c1ceb9&_e=2HooBw679Yaq-U3iqrkzcwYX6p8qqaPky-EvlczCsrSVI2Y2r4nIJZtMvsXpiimf0EGRYTUGgDUlt_KbjqEhX-UJIBSCcRxmFa1fEQO3kkGX9EKGrx2EtMs2hI9neugFs0RUxOsaraCSMvrh3IjKFaJeSmjDXE-eT3iMy8IADXN37U_7E8G8ud7isAztCqf6ck-kJgAZThlCq2p0vbmwf3X8qWJx_BeqE1XBElbqFvvhDxiDpqrVKYXGo2z6chN5IckRqqQTO8WRjCRBRbo_0bpbsm58BgffwuroosL0lddtxlssnf2EnJGHk2tPVeVsT1N2nbS1_ftKdyAWqcXP1wgfkpPu6cx_C94ioNNC_IuhYrfYqTkacLwD7nmzoHrQbWhAVEXq5-WjiSqjHY9jpg%3D%3D
It gets truncated to:
http://links.mountaingoatsoftware.com/u/click?_t=63a7abd958e4476e981f7dfae6360e05&_m=b290e0f87fe44df3a8d81f5945c1ceb9&_e=2HooBw679Yaq-U3iqrkzcwYX6p8qqaPky-EvlczCsrSVI2Y2r4nIJZtMvsXpiimf0EGRYTUGgDUlt_KbjqEhX-UJIBSCcRxmFa1fEQO3kkGX9EKGrx2EtMs2hI
Comments (22)
-
repo owner -
repo owner -
repo owner After looking at the code, the URL is not truncated by the form as I thought. It works fine when I put it in myself. I think Windows or your mail program is doing the truncation. How are you opening this link? Outlook?
-
Yes, from Outlook 2016. Although I just put it in the Run box (Win+R) and I get the same result.
-
repo owner I see what is happening. Looks like it get truncated before BC2 even starts. however, I know how to fix this, but required a bit code.
-
repo owner Actually, you can implement a fix right now without new code. It requires to edit the Registry
Go to the following location: HKCU\Software\Classes\BrowserChooser2URL\shell\open\command
Modify (Default) at the end where it says "%1" to ""%1"". Yes, 2 double-quotes. This worked for me. Let me know if it works for you and I will modify the code to use this.
-
Hmm, didn't seem to make a difference.
-
This is actually getting truncated by explorer.exe due to MAX_PATH.
Browser Chooser 2 uses explorer.exe to launch the URL prepended with
microsoft-edge:
, e.g.microsoft-edge:https://bitbucket.org/gmyx/browserchooser2
. However, explorer.exe interprets the command line argument as a path, truncating the total length of the string to 260 including a null terminator. Withmicrosoft-edge:
being 15 characters, that leaves only 244 characters for the URL (260 - 1 - 15 = 244).I tried passing the URL cmd.exe instead (e.g.
cmd.exe /c start microsoft-edge:<url>
) but then I ran into issues with needing to escape the string as mentioned in this StackOverflow answer.I think the best option would be to have a special case for Edge and just call
Process.Start("microsoft-edge:<url>")
. -
repo owner Interesting. The only way I ever got it work was via explorer.exe. I don't think I can process.start edge directly but will try it.
-
repo owner Process.start does indeed work for edge. That makes things much easier.
-
repo owner - changed status to open
-
repo owner - changed milestone to Release 1.1
- changed component to Launching Browser
- changed version to Release 1.1
-
repo owner - changed version to Release 1
-
Any progress on releasing this fix? Would it be safe to grab your latest commit and compile it locally?
-
repo owner I am waiting on one last thing before I make a release. No exact date yet.
You could grab the latest commit, it should work. I think it is a bit behind because of a small experiment in progress.
-
The changes for Edge work (including the URL truncation) work well. However, on a release build it seems throw an access violation trying to launch Chrome. (I have an Auto URL set up to launch a specific domain in Chrome instead of Edge.) The access violation is in BrowserUtilities.DoLaunch() at BrowserUtilities.vb line 94:
If WinAPIs.GetFileAttributesEx(strBrowser, GET_FILEEX_INFO_LEVELS.GetFileExInfoStandard, lInfo) = True Then
-
repo owner Interesting. I haven't started testing yet. I wonder if UAC is blocking reading a file program files. I will need to test when I get a chance tonight.
-
repo owner Gotta love the weirdness of code sometimes. Changing the build form Debug to release changed the target platform. Debug has it AnyCPU while Release was at x86. Setting the target to AnyCPU fixes this problem.
Why? Not a clue.
-
Confirmed; that fixed the access violation for me.
-
repo owner - changed milestone to Release 2
-
repo owner - changed status to resolved
Fixed in Release 2, out now.
-
Works great!
- Log in to comment
Opps. That was supposed to happen for only the from title.