Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#91 closed bug (fixed)

Text and graphics problem on network window of OWB

Reported by: Samir Hawamdeh Owned by:
Priority: normal Milestone: 4.0-2015R1
Component: List.mui Version: 4.0-nightly build
Severity: minor Keywords:
Cc: Roman Kargin OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

Similarly to the already reported bug #30 the network window of Odyssey sometimes will be broken aswell, text will just disappear and there are some graphically corruptions visible when you try to move the scrollbar

Actually i don't know how to reproduce it, maybe it happen when a particular URL address exceeds a certain size.

A grab is attached

Attachments (2)

network_window.png (328.9 KB) - added by Samir Hawamdeh 5 years ago.
trash.jpg (164.6 KB) - added by Thore Böckelmann 5 years ago.
New screenshot from samo79

Download all attachments as: .zip

Change History (25)

comment:1 Changed 50 years ago by Samir Hawamdeh

Status: pendingnew

Changed 5 years ago by Samir Hawamdeh

Attachment: network_window.png added

comment:1 Changed 5 years ago by Thore Böckelmann

Unfortunately I have no idea what might be causing this. Roman and I tried already lots of things to pin point a certain reason, but without luck yet.

Unless there is no more or less easy way to reproduce this issue 100% either in Odyssey or in any other MUI application you will have to live with this bug.

comment:2 Changed 5 years ago by Thore Böckelmann

Status: newpending

Have you been able to witness this issue in any kind of a reproducible way? By downloading something from a certain and fixed URL perhaps?

Last edited 5 years ago by Thore Böckelmann (previous) (diff)

comment:3 Changed 5 years ago by Samir Hawamdeh

Not yet, maybe it happen when certain (particularly long) addresses will be loaded inside the Network window, but in general we doesn't have any problem even when such long address still loading, so to be honest i don't know exactly how to reproduce and why .. sometimes happen and sometime not

To verify the best method would be to keep the network activity's window opened all the time and then browse the net for some time ..

I will recheck, meantime pls keep the ticket on hold ..

comment:4 Changed 5 years ago by Samir Hawamdeh

Mmm i was able to reproduce the issue, but in a very strange way.

For a reason that eventually i will explain you later I commented out the whole MUI folder in Env-Archive, so at next restart OWB (and of course any MUI programs in general) would have a completely resetted preferences

Now i open OWB, then its network window (during a loading of a page) and i see again the issue, see grab

comment:6 Changed 5 years ago by Thore Böckelmann

Please don't use external links where the linked stuff can vanish at any time. Attachment can be done here directly. Nothing will be deleted here automatically. Nothing is worse than not beimg able to be unable to access such files for reference at some later time.

Version 0, edited 5 years ago by Thore Böckelmann (next)

Changed 5 years ago by Thore Böckelmann

Attachment: trash.jpg added

New screenshot from samo79

comment:7 Changed 5 years ago by Thore Böckelmann

Which screenmode are you using? 16 bit or 32 bit? I am using a 16bit Workbench only, because the embedded Radeon7000 of my µA1 is equipped with only 32MB VRAM which is not enough to open more than a single 1280x1024x32 screen. Perhaps this effect is limited to 32bit screens and doesn't happen on 16bit screens.

comment:8 Changed 5 years ago by Samir Hawamdeh

Please don't use external links where the linked stuff can vanish at any time.

Yep sorry, but on the direct reply i didn't found the "attach file" checkbox, and i noted this only *after* i wrote you about the availibility of the attach .. so instead of searching for that checkbox i prefer the easier solution, aka an external site :-)

Aniway theorically the attach checkbox should be placed just below the textarea where are we typing, but where are ?

Which screenmode are you using? 16 bit or 32 bit? I am using a 16bit Workbench only, because the embedded Radeon7000 of my µA1 is equipped with only 32MB VRAM

My screenmode is 32 Bit:
Radeon 9250: 1680*1050 ARGB32

comment:9 in reply to:  8 Changed 5 years ago by Thore Böckelmann

Replying to samo79:

Aniway theorically the attach checkbox should be placed just below the textarea where are we typing, but where are ?

It is placed at the top below the "Summary" text box. It has always been there, even in the YAM bugtracker, and I don't know if it can be moved. This is something only Jens can comment on.

My screenmode is 32 Bit:
Radeon 9250: 1680*1050 ARGB32

Ok, that supports my assumptions. I doubt that the resolution does have any impact, because List.mui is dealing with aribtrary wide virtual areas here. Only the the depth could be the culprit, because it limits the maximum allowed width of a temporary bitmap which List.mui uses to prepare everything before the result is finally displayed on the screen.

comment:10 Changed 5 years ago by Samir Hawamdeh

I just found an interesting testcase trying to download a big "russian" image from Wikipedia, it's very big in size ( 4 MB ) and it have a very long cyrillic name.
With this image the well know glitch on the download window is finally 100% reproducible, that's interesting and might help you to understand why we have this type of glitch also on other areas

Try to load this image with Odyssey:

http://upload.wikimedia.org/wikipedia/commons/c/c9/%D0%92%D1%81%D1%82%D1%80%D0%B5%D1%87%D0%B0_%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0_%D0%B8%D0%BD%D0%BE%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D0%B4%D0%B5%D0%BB_%D0%94%D0%BE%D0%BD%D0%B5%D1%86%D0%BA%D0%BE%D0%B9_%D0%9D%D0%B0%D1%80%D0%BE%D0%B4%D0%BD%D0%BE%D0%B9_%D0%A0%D0%B5%D1%81%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B8_%D0%95%D0%BA%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%BD%D1%8B_%D0%93%D1%83%D0%B1%D0%B0%D1%80%D0%B5%D0%B2%D0%BE%D0%B9_%D0%B8_%D0%93%D0%BB%D0%B0%D0%B2%D1%8B_%D0%A0%D0%B5%D1%81%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B8_%D0%9A%D1%80%D1%8B%D0%BC_%D0%A1%D0%B5%D1%80%D0%B3%D0%B5%D1%8F_%D0%90%D0%BA%D1%81%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0.JPG

Then during loading (or after the download are done), try to download it verifying if your download window will be "corrupted" or not

comment:11 Changed 5 years ago by Thore Böckelmann

Cc: Roman Kargin added

Damn! It seems the 256MB main memory of my µA1 are simply not enough. If I manage to go to the page without a system lock up but without the image being displayed due to not enough free memory on a 16bit 1280x1024 Workbench thé address is displayed fine in the Network window. And even switching to a 32bit mode doesn't make a difference except causing the lock up to happen a bit faster.

Unfortunately I cannot afford a more recent machine which might be able to handle this large image.

So if possible please try to find another page which causes this effect but is not that "demanding" in terms of memory.

comment:12 Changed 5 years ago by Thore Böckelmann

Please try to reproduce this issue with the next nightly build. As stated in #115 there was an ancient bug in MUI's layout engine which prevented certain list columns to become wider than approx 1000 pixels. Perhaps this is related to this issue. However, this is just a wild guess.

comment:13 Changed 5 years ago by Samir Hawamdeh

Hi Thore,

Please try to reproduce this issue with the next nightly build

Tested now with the latest r4212 but i have the same problem, when downloading the image above i still have various (graphical) glitch on the download window :-(

So if possible please try to find another page which causes this effect but is not that "demanding" in
terms of memory.

Ok i will search another image, eventually i can try to resize it too

comment:15 Changed 5 years ago by Samir Hawamdeh

@Thore

Found another site that is able to reproduce the issue :-)
Keep the network window of Odyssey opened and then load: http://www.amikit.amiga.sk/

comment:16 Changed 5 years ago by Thore Böckelmann

Ok, I managed to reproduce this issue here once after going back from the AmiKit link to this page. Unfortunately the buffer management of WebKit seems to be quite buggy and crashes very often because of accessing a NULL pointer. This makes it very hard to reproduce the issue easily. Even worse it does not happen every time. If only someone could point me to an easier was to reproduce it…

comment:17 Changed 5 years ago by Samir Hawamdeh

Strange, tested again and again and i can replicate the issue everytime i visit the AmiKit website, aniway did you tried with the image links of my previews post above ?

Sure that affected the download window instead, but i suspect it might be related to the same bug

comment:18 Changed 5 years ago by Thore Böckelmann

The file is downloaded without any graphical corruption.

comment:19 Changed 5 years ago by Thore Böckelmann

#137 is a duplicate of this issue.

comment:20 Changed 5 years ago by Thore Böckelmann

This issue should be fixed with the next nightly build. At least for me everything is working correctly now. Please reopen the ticket otherwise.

comment:21 Changed 5 years ago by Thore Böckelmann

Component: muimaster.libraryList.mui
Milestone: MUI 4.0-2015R1
Priority: undecidednormal
Resolution: fixed
Status: newclosed

comment:22 Changed 5 years ago by Thore Böckelmann

Milestone: MUI 4.0-2015R14.0-2015R1

Milestone renamed

Note: See TracTickets for help on using tickets.