@mattab opened this Issue on August 6th 2010 Member

When I go to http://demo.piwik.org using Google Chrome on windows XP, the dashboard first partly loads, then the dashboard visibly reloads itself. This is def not expected.

@peterbo commented on August 16th 2010 Contributor

Attachment: Replaces the $.browser.chrome browser-detection hack with a short workaround. Please check, because I'm no JS hero! I tested in Chrome / IE8 / FF3 / Safari and the x-offset of the control-icons seemed ok.

@robocoder commented on August 7th 2010 Contributor

In IE8 on Vista, I was getting a lot of console errors, "Object doesn't support this property or method". Disabling the PDFReports plugin seemed to fix this.

@peterbo commented on August 7th 2010 Contributor

This behaviour is somehow caused by the visitor country map plugin. Disabling it, fixes the problem.

@mattab commented on August 16th 2010 Member

I can confirm that issue is caused with the Maps widget.

Peter, good stuff. I'm curious, how did you find out the cause?

@peterbo commented on August 16th 2010 Contributor

This was not a big deal. I was able to reproduce the bug with the current trunk but not with the current install on a webserver. The only difference between these two installs was the World-Map plugin.

The problem could be further tracked down to line 21 in worldmap.tpl
Since it is a chrome-specific issue it could either be a bug in chrome js engine or an error with a conditional comment for chrome

$.browser.chrome = /chrome/.test(navigator.userAgent.toLowerCase());

deleting it seems to fix the issue (please confirm).

Further info to the browser detection of jquery: http://api.jquery.com/jQuery.browser/

JQuery.browser - object seems to be deprecated as of version 1.3.

Now the JQuery.support-object should be used instead to determine if the browser supports w3c boxModel etc.:

@gka commented on August 16th 2010 Contributor

I had to introduce this line because the default jQuery browser detection makes no difference between Safari and Chrome but both browsers have different ways of calculating the width of a html select element. I don't think that this issue is connected to the box-model bug.

There are serveral work-arounds for this:

  • we find a way to detect Safari that doesn't force Chrome to reload the page
  • we define a fixed width for the html select
  • we hard-code the select widths for every translated language
  • we just don't care about the users of buggy Safari
  • we throw away the fullscreen feature from the icon bar (it would only be accessible via context menu)
  • we break the UI consistency by aligning the icons to the right
@gka commented on August 16th 2010 Contributor

The fix looks good, I'll commit this. Thanks a lot :)

@gka commented on August 16th 2010 Contributor

(In [2950]) added bug-fix from peterB (fixes #1561)

@peterbo commented on August 16th 2010 Contributor

Greg, I think there is also a Variable to be changed on line 71.

@gka commented on August 16th 2010 Contributor

Oh yes, I forgot to fix this because this is a very unnecessary line. The select elements width doesn't change as the browser window width changes. I'll remove it..

@peterbo commented on August 17th 2010 Contributor

"{" and "}" are no valid strings to capsule js comments, please fix as it is in .diff file.

Can be checked here:

Sorry, my fault - it's a Smarty Comment and therefore it's ok!

@gka commented on August 17th 2010 Contributor

I think these are Smarty comments which doesn't appear in the html output.

This Issue was closed on August 17th 2010
Powered by GitHub Issue Mirror