Bug 143699

Summary:	[regression] images which are loaded in a background tab are not shown
Product:	[Applications] konqueror	Reporter:	michaell <michaell>
Component:	general	Assignee:	Konqueror Bugs <konqueror-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	martin, rpogomes, samuel.brack
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	imageLoading_fix.patch

Description michaell 2007-04-01 17:20:45 UTC

Version:            (using KDE KDE 3.5.6)
Installed from:    Gentoo Packages

One example is http://www.deviantart.com. Due their small bandwidth I usually try to preload the images in the background

1. open one (bigger) image in a new tab
2. click on it to get the orginal size
3. get back to another tab
4. after the image loaded, switch back to the new tab and the image isn't visible


Another e.g., this time without java script: http://www.pbase.com/galleries

1. open one image from a gallery in a new tab
2. if the label of the new tab gets updated with the images name, quickly switch back to another tab.
3. after the image loaded, switch back to the new tab and the image isn't visible

It worked fine in KDE 3.5.5

Comment 1 michaell 2007-05-24 06:26:14 UTC

addition:
It's correlated to the fix for #91240 and it affects also probably the most animations.
It seems KHTMLView::showEvent(QShowEvent* e) isn't called here and thus the animation doesn't resume or gets shown.

Comment 2 Rui G. 2008-06-17 12:45:09 UTC

Can you still reproduce that behavior? I tried in 3.5.9 and trunk but all the images are loaded despite following those steps.

Comment 3 michaell 2008-06-18 00:35:47 UTC

Created attachment 25432 [details]
imageLoading_fix.patch

Yes, it's still broken. I guess you was just to slow when switching to another
tab before the image loading has finished. Try some bigger images.
I couldn't reproduce it with trunk also, but the "disable animations" feature
doesn't work and if it's realated, it may just look fixed, but show/hideEvent()
seems to be called now in trunk.

I use the attached patch to "fix" it. It just disables the feature.

Comment 4 Samuel Brack 2011-01-09 23:11:25 UTC

Hm, I can't confirm this. Is this bug still present?

Comment 5 Martin Koller 2011-06-04 21:24:18 UTC

can not reproduce with 4.6.3