Opened 4 months ago

Last modified 2 weeks ago

#429 reopened bug

Possible chars limit in data:image URLs (Odyssey)

Reported by: Samir Hawamdeh Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2020R2
Component: String.mui Version: 5.0-2019R4
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

I'm not sure if this is a MUI bug or just an Odyssey specific one, however i found a funny bug in search address area of OWB that i can reproduce with every versions of this browser

To reproduce it, do this step passages:

1) Identify your browser as IPad 6.1
2) Open Google, and type something to search, for example: "Odyssey Web Browser aros"
3) Now in Google search, choose "image" (so to search for images the text you typed)
4) When thumbnails will be loaded, right click into any of that image and select —> open image in new tab

Grab attached

Very very long URLs such the one generated from data:image that exceed certain limit of chars (in this specific case we exceed the crazy number or 12304 chars!) will f*d the addressbar …

Still to see if this is MUI problem or just something a limit "imposed" by Odyssey

Attachments (4)

FastView_Capture_T200312_144204.jpg (218.3 KB) - added by Samir Hawamdeh 4 months ago.
extraurl.txt (3.7 KB) - added by Roman Kargin 4 months ago.
url_distortion
FastView_Capture_T200322_005235.jpg (209.2 KB) - added by Samir Hawamdeh 4 months ago.
url_selected.jpg (187.2 KB) - added by Samir Hawamdeh 3 months ago.

Download all attachments as: .zip

Change History (15)

Changed 4 months ago by Samir Hawamdeh

comment:1 Changed 4 months ago by Roman Kargin

@Thore
A more easy way to reproduce the issue is just to copy+paste data from my attached example to the URL-bar, then type one more single character to have things mess up.

Through while its 3784 symbols ok, and +1 typed symbol start to create a mess in the URL bar, when I pure typed 3784 of "a" characters, then I can type more without distortion. So it seems not exactly the amount of character-related (or, they should be different to fill memory differently). With pure http://aaaaaaa , it just needs more characters to get things messed up, but they will be messed up, just need to type more.

Last edited 4 months ago by Roman Kargin (previous) (diff)

Changed 4 months ago by Roman Kargin

Attachment: extraurl.txt added

url_distortion

comment:2 Changed 4 months ago by Thore Böckelmann

Component: undefinedString.mui
Milestone: future release5.0-2020R1
Priority: undecidednormal
Status: newaccepted

The problem is that String.mui uses graphics/TextExtent() internally to calculate the pixel width of the text to be displayed. Depending on the used font and the string length the resulting pixel width will eventually be larger than 32767 and hence be negative, because TextExtent() does its calculation with signed 16bit integers only. And negative numbers can cause arbitrary misbehaviour further functions of graphics.library.

I will see how I can fix that.

comment:3 Changed 4 months ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Resolution: fixed
Status: acceptedclosed

In 6542:

  • String.c, mastertext.c: use the 32bit based text dimension calculation functions. For String class the string length passed to Text() is limited to 2048 characters to avoid internal integer overflows due to signed 16bit dimension calculations and may garble very long strings. This closes #429.

comment:4 Changed 4 months ago by Samir Hawamdeh

Tested with latest #6542 but the bugs seems not solved, grab attached

To reproduce it:

1 - Open Odyssey
2 - Identify Odyssey as IPad 6.1
3 - Open this link:

https://www.google.com/search?q=odyssey+web+browser+aros&prmd=isnv&source=lnms&tbm=isch&sa=X&ved=2ahUKEwjtgpSO4azoAhXw-yoKHXE2CfsQ_AUoAXoECAwQAQ

Now right click into one of the grab of OWB for AROS, and open the image in a new tab, then open it

Changed 4 months ago by Samir Hawamdeh

comment:5 Changed 4 months ago by Thore Böckelmann

Resolution: fixed
Status: closedreopened

I can confirm the behaviour even on OS3. The double printing happens with strings far longer than 10000 characters only. Before it could happen that nothing was displayed at all. But in essence it all comes down to an integer overflow of signed 16bit integers.

comment:6 Changed 4 months ago by Thore Böckelmann

In 6543:

  • String.c: print out text in portions of 1024 characters at most and check for overflows of the cursor position to bail out early. This refs #429.

comment:7 Changed 4 months ago by Thore Böckelmann

In 6544:

  • String.c: correctly draw the background for very long content strings. This refs #429.

comment:8 Changed 4 months ago by Thore Böckelmann

The current state will correctly display the first part of very long strings, but the last part will be invisible due to the shortened output of r6543. I'll still have to find a solution for this.

comment:9 Changed 3 months ago by Samir Hawamdeh

Ok tested the latest r6545 and we have some progress here, however as you said still not perfect yet

See grab attached (url_selected.jpg)

Now when we open a tab with such long uri address there is no garbage anymore in text, but if we try also to select that text, It happens that the text of the URL will completely disappear, and in the space of when the mouse cursor should be, we have instead a sort of small blue lines (not visible in the attached grab but they still)

In short as you said the first part of the problem is fixed when such long url text is presented to the user, but still buggy when we try to manually handle it, selecting etc …

Last edited 3 months ago by Samir Hawamdeh (previous) (diff)

Changed 3 months ago by Samir Hawamdeh

Attachment: url_selected.jpg added

comment:10 Changed 3 months ago by Thore Böckelmann

I didn't say the issue is solved perfectly or completely at all. This is still work in progress.

comment:11 Changed 2 weeks ago by Thore Böckelmann

Milestone: 5.0-2020R15.0-2020R2

This issue requires a major rewrite of String class. Currenty it always handles the full contents and does 32bit coordinate calculation to display the visible part. However, graphics.library can handle 16bit coordinate only and hence the position overflows internally which causes the multiple display.

Note: See TracTickets for help on using tickets.