Details
-
Bug
-
Resolution: Done
-
P4: Low
-
None
-
None
-
Konqueror / khtml browser (4.4, 4.5 and 4.6 pre-alpha)
Description
When scrolling in bug pages like in http://bugreports.qt.nokia.com/browse/QTBUG-15052, scrolling down produces a weird effect of the text going in the wrong direction.
This is not a bug in the web engine. It's a bug in the JavaScript code that tries to scroll in JIRA and doesn't do proper browser detection. In other words, the workaround for another browser's bug is creating an issue for this browser.
This is probably an upstream issue.
Pasting the analysis here:
Broken website due to UA sniffing. The scrolling is actually done in JS, which
calls the following function:
function needToApplyFlickerFix()
{
var browserVersion = jQuery.browser.version.replace(/\.*/g,
"").substring(0, 3);
return jQuery.browser.mozilla && browserVersion < 192;
}
(backtrace: needToApplyFlickerFix(), initialize(), setStalkerPosition in
jira.webresources:viewissue.js)
... which errors out since jQuery.browser.version is never set with our UA
string, as it's initialized as follows:
"uaMatch": function (a)
{
a = a.toLowerCase();
a = /(webkit)[ \/]([\w.]+)/.exec(a) || /(opera)(?:.*version)?[
\/]([\w.]+)/.exec(a) || /(msie) ([\w.]+)/.exec(a) || !/compatible/.test(a) &&
/(mozilla)(?:.*? rv:([\w.]+))?/.exec(a) || [];
return { "browser": a[1] || "", "version": a[2] || "0" };
}, "browser": { } });
P = c.uaMatch(P);
if (P.browser)
{
c.browser[P.browser] = true;
c.browser.version = P.version;
}
if (c.browser.webkit)
c.browser.safari = true;
... which means if you're not using one of the predefined strings,
jQuery.browser is never set beyond the initial empty object.
Workaround: UA fake.