Bug? - Incomplete grabbing of a URL

[midas02]

Hi Mouser,

First of all, thanks for the great software. I've been using it for years.

I've found some unexpected behaviour though. Could you open the following link in a browser, whilst you've got URL Snooper sniffing?
http://vod.medialaan...9492114001611_148959

URL Snooper will then tell me it found a link "http://vod.medialaan.io/api/1.0"... no mentioning of the rest of the link. Even stranger, when I filter the URLs on the word "callback", that URL still shows up, although it has been truncated by URL snooper, so it isn't even clear why that URL has been identified as a match. But, when I right-click on that match, and do a "Copy link to clipboard", the FULL link is being copied, and not the truncated one.

So, clearly, the link is correctly being sniffed, in full, but it starts going wrong when displaying it on the screen. Am I missing something, is this expected behaviour? Let me know if you would have a hard time reproducing it, I'll post a screenshot.

Thanks!

[mouser]

If you wouldn't mind, a screenshot would help clarify the issue.

[midas02]

Ok, I've encircled the culprit in red. As you can see, URL Snooper doesn't show the full link. It only seems to display the beginning of the link. Take notice as well of the fact that I have been filtering on the word "callback". Which filters out that particular link, although the main screen doesn't give you any hint on why there was a match. It's only when you check the full packet content, that one starts to understand why.

And still, when right-clicking, "copy URL", it is the full URL which is being copied, and not the truncated one which is being displayed.

[mouser]

Thanks that helps -- I agree it shouldn't be doing that.. I will fix. 

[mouser]

Can you try the latest beta and let me know if it's fixed?
Link at top of this page: https://www.donation...dex.php?topic=1772.0

[midas02]

It's fixed.

[mouser]

 

[midas02]

That was quick, thanks.

Some other questions. What does "First High-dpi compatible version beta" on the change log mean?

And what are these buttons for? They seem to be new.

[mouser]

Some other questions. What does "First High-dpi compatible version beta" on the change log mean?

It's for people who have their windows display options set to > 100% text size, typically users with super hi-res 4k monitors.  For everyone else it should hopefully have no effect.

Those buttons are used to manually step through packets one at a time.  You would first click "Pause" and then click "Parse 1" for each new packet you want to parse, while the new packets are buffered in a queue.
It can be useful if you need to examine all packets as they come in from a requested stream, though note that it's really only useful in the initial packets as there will quickly be too many to examine..

[wraith808]

Funny thing is, I have a high DPI monitor without the font set to over 100%, and I've never had a problem with any of your applications, even though others, I have terrible problems with on the same settings.  Strange.  But great that you're getting all of them updated!

[mouser]

Funny thing is, I have a high DPI monitor without the font set to over 100%, a

Well I guess I should refer to these fixes as fixes for those with Windows Text Size setting over 100%, as that is what is improved -- regardless of the resolution.  Hopefully these latest fixes won't cause any issues for those with 100% text size setting.

[wraith808]

Funny thing is, I have a high DPI monitor without the font set to over 100%, a

Well I guess I should refer to these fixes as fixes for those with Windows Text Size setting over 100%, as that is what is improved -- regardless of the resolution.  Hopefully these latest fixes won't cause any issues for those with 100% text size setting.

-mouser (March 17, 2017, 07:47 PM)

No, I think you're fine.  The ones that I have problems with, I didn't have my text set to over 100% either.