Version: 4.1.2 (KDE 4.1.2) (using 4.1.2 (KDE 4.1.2), Kubuntu packages) Compiler: gcc OS: Linux (x86_64) release 2.6.24-16-generic In kde 3, konqueror works with jcarousel (http://sorgalla.com/jcarousel) - in kde 4 it does not, trying to load the examples at sorgella.com it simply freezes at 25 %, requiring a kill to stop the application.
Setting the UA to 'Safari 2.0 on Mac OS X' makes it work, But I repeat that it works with kde 3 konqueror, so that should NOT be nessecary.
I can confirm the problem in 4.1.2 (Kubuntu), for example with the "Simple carousel". However, trunk rev. 871890 (with default UA) shows a dialog box "jCarousel: No width/height set for items. This will cause an infinite loop. Aborting...". Konqueror doesn't freeze then, but the carousel doesn't work either. Maybe it's a bug in 4.1.x that is fixed already in trunk?
The reason it works using the safari ua string is that the script looks for safari and calculates the width. Maybe it was worth trying with other webkit based browsers? I'm not familliar with the internals of HTML rendering and javascript engines, but I assume that gecko and MSHTML calculates such values on demand.
I tried different UA settings in trunk and experimented a bit. On the first load of the "Simple carousel" example (middle-clicked the link to open in another tab), I get an error message for Konqueror, Firefox and IE, but no error for Safari. The carousel doesn't work. Loading the example a second time in a new tab, there are no error messages, and the carousel works fine for any UA setting. Strange... 4.1.2 (Kubuntu) freezes for me for Konqueror, Firefox and IE UA settings, but not for Safari. I don't know where the problem is, but I'll change the component to 'KHTML' because that's probably closer to it than 'general'.
As I said, the script contains some special cases for safari. Which is why I wonder how other webkit browsers behave (and what their UA strings are)
We're getting renderer:0 when offsetWidth is called... And oddly enough an alert "fixes" it, which ought not matter if it's just display:none..
*** Bug 174250 has been marked as a duplicate of this bug. ***
Thank you for the bug report. As this report hasn't seen any changes in 10 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
I don't think this has any relevance any longer.