On Mon, Sep 9, 2013 at 2:32 PM, Marcus (OOo) <marcus.m...@wtnet.de> wrote: > Am 09/09/2013 07:50 PM, schrieb Rob Weir: > >> On Fri, Sep 6, 2013 at 3:33 AM, Marcus (OOo)<marcus.m...@wtnet.de> wrote: >>> >>> Am 09/06/2013 03:18 AM, schrieb Rob Weir: >>> >>>> On Thu, Sep 5, 2013 at 4:32 PM, Marcus (OOo)<marcus.m...@wtnet.de> >>>> wrote: >>>>> >>>>> >>>>> Am 09/05/2013 10:20 PM, schrieb Rob Weir: >>>>> >>>>>> On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)<marcus.m...@wtnet.de> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Am 09/05/2013 12:20 AM, schrieb Rob Weir: >>>>>>> >>>>>>>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<marcus.m...@wtnet.de> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 09/04/2013 10:47 PM, schrieb Rob Weir: >>>>>>>>> >>>>>>>>>> http://browsershots.org/http://www.openoffice.org/download/ >>>>>>>>>> >>>>>>>>>> I'm not sure anyone else can read that. It might be tied to a >>>>>>>>>> cookie. >>>>>>>>>> But I ran a test to render the download page on 135 >>>>>>>>>> browser/os >>>>>>>>>> combinations. It returns a PNG screenshot for each rendering. I >>>>>>>>>> looked for which combinations did not render the green download >>>>>>>>>> box. >>>>>>>>>> >>>>>>>>>> There were 5 failures. Two I don't think we care about: >>>>>>>>>> >>>>>>>>>> Dillo 3.0.2 / Debian 6.0 (squeeze) >>>>>>>>>> >>>>>>>>>> and >>>>>>>>>> >>>>>>>>>> Kazehakase 0.5.8 / Debian 6.0 (squeeze) >>>>>>>>>> >>>>>>>>>> And 3 that we should care about: >>>>>>>>>> >>>>>>>>>> MSIE 5.5 / Windows 2008 R2 (Server) >>>>>>>>>> >>>>>>>>>> MSIE 6.0 / Windows 2008 R2 (Server) >>>>>>>>>> >>>>>>>>>> MSIE 7.0 / Windows 2008 R2 (Server) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't agree here. Why do we have to support stone-old browsers? >>>>>>>>> Because >>>>>>>>> they are available on a browser testing website? Come on. ;-) >>>>>>>>> >>>>>>>> >>>>>>>> I'm concerned with the error, since it it impacts the more modern IE >>>>>>>> 6 >>>>>>>> and >>>>>>>> 7. >>>>>>>> >>>>>>>> Looking at visits to our website over the past month I see this many >>>>>>>> users: >>>>>>>> >>>>>>>> IE 10 -- 857,499 >>>>>>>> IE 9 -- 250,591 >>>>>>>> IE 8 -- 420,215 >>>>>>>> IE 7 -- 69,914 >>>>>>>> IE 6 -- 27,172 >>>>>>>> IE 5.5 -- 69 >>>>>>>> >>>>>>>> So we're still getting nearly 100K visits/month from these older IE >>>>>>>> versions. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The 69 are not really impressive. But 27,000+ for MSIE 6 is >>>>>>> surprising. >>>>>>> >>>>>>> >>>>>>>>> http://en.wikipedia.org/wiki/Internet_Explorer_5 >>>>>>>>> >>>>>>>>> It's old, MS is no longer supporting it, so IMHO it's done. Nearly >>>>>>>>> the >>>>>>>>> same >>>>>>>>> for 6.0. >>>>>>>>> >>>>>>>> >>>>>>>> Right. But here is a common scenario. You need to reinstall >>>>>>>> Windows >>>>>>>> on a machine. Say it is XP or Vista. Both are supported today, but >>>>>>>> both have older browsers by default. Of course, the first thing you >>>>>>>> do on a new machine is run the Windows Updates. But in parallel >>>>>>>> with >>>>>>>> that you are downloading other software you need, Acrobat Reader, >>>>>>>> anti >>>>>>>> virus, 7-Zip, Notepad++, etc., and Apache OpenOffice. So you >>>>>>>> might >>>>>>>> end up with IE 8 in the end, after all the patches are applied. But >>>>>>>> you start your work with an earlier version, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I would expect that these people first get the basics up-to-date, >>>>>>> then >>>>>>> other >>>>>>> applications. >>>>>>> >>>>>>> >>>>>>>>>> The IE versions all give the same script error: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> However, if all browsers show the same error then a fix could get >>>>>>>>> back >>>>>>>>> all 3 >>>>>>>>> into life at the same time. >>>>>>>>> >>>>>>>> >>>>>>>> That makes sense. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, let's concentrate on the error. >>>>>>> >>>>>>> >>>>>>>>>> Line 330, Char 1, Code 0, Expected identifier, string or number >>>>>>>>>> >>>>>>>>>> This is an odd place for an error, since that appears to be in the >>>>>>>>>> middle of the commented out block for beta releases. >>>>>>>>>> >>>>>>>>>> Any ideas? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, if you search in the "index.html" which indeed doesn't make >>>>>>>>> sense. >>>>>>>>> >>>>>>>>> When looking into "download.js" then you are in the middle of the >>>>>>>>> "getFilesize()" function. But I've no idea what the problematic >>>>>>>>> point >>>>>>>>> could >>>>>>>>> be there. >>>>>>>>> >>>>>>>> >>>>>>>> I wonder if it could be >>>>>>>> http://www.openoffice.org/download/release_matrix.js? Could it be a >>>>>>>> coincidence that that file is exactly 329 lines long and the error >>>>>>>> is >>>>>>>> claimed to be in line 330? Maybe that unnecessary comma at the end >>>>>>>> of >>>>>>>> line 328 is the issue? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hm, and what about "languages.js"? It has also a semicolon at the end >>>>>>> but >>>>>>> the file has only 108 lines. In the "index.html" it will be imported >>>>>>> before >>>>>>> the "release_matrix.js" (I don't know if this really the case) but >>>>>>> there >>>>>>> is >>>>>>> no hint for error. >>>>>>> >>>>>>> Anyway, let's try. In the test area: >>>>>>> >>>>>>> http://ooo-site.staging.apache.org/download/test/index.html >>>>>>> http://ooo-site.staging.apache.org/download/test/other.html >>>>>>> >>>>>>> I've committed the deletion of the characters in both files. I think >>>>>>> we >>>>>>> need >>>>>>> to wait another 24h until we are allowed to use Browsershots.org >>>>>>> again, >>>>>>> right? - At least this is my experience. >>>>>>> >>>>>> >>>>>> I don't know if that restriction is per client IP address or per host, >>>>> >>>>> >>>>> >>>>> >>>>> It's about the tested website that triggers the limit. It doesn't >>>>> matter >>>>> who >>>>> or which IP is requesting the test. >>>>> >>>>> >>>>>> but we're blocked either way, because of robots.txt on staging: >>>>> >>>>> >>>>> >>>>> >>>>> OK yes, the staging area. >>>>> >>>>> >>>>>> http://ooo-site.staging.apache.org/robots.txt >>>>>> >>>>>> But if it is OK to publish those changes we should be able to run >>>>>> another test now. >>>>> >>>>> >>>>> >>>>> >>>>> Hm, I decided to publish the changes already yesterday. To bad that >>>>> I've >>>>> not >>>>> changed the links from staged to live, sorry. ;-( >>>>> >>>>> Please try again with the real webpages. >>>>> >>>> >>>> Same errors. >>>> >>>> I think it is the trailing comma on the last entry in the array. I >>>> changed in it download/test/release_matrix.js and will test it again >>>> tomorrow. >>> >>> >>> >>> Ah, good catch. I've published the website, so you can test with the real >>> webpage. >>> >>> I cross my fingers. >>> >> >> The latest versions works OK on the older I.E.'s on browsershots.org. >> >> I also found this online tool for checking JavaScript: >> >> http://www.javascriptlint.com/online_lint.php > > > Thanks for the link. Really a handy, fast and helpful tool. > > >> It says the final semi-colon is fine, but the trailing comma is no. > > > OK, then let's keep the semi-colon but delete the comma. > > >> I'm happy to make these changes to the live version, but I'll check >> with you to make sure you don't have some other pending merges first. > > > Wow, I never thought that we would find the problem that fast. Thanks for > your help. Therefore - as you have found the comma as the root cause - I'll > leave you the honor to commit the fix. >
Great. I'll do that. Of course, there is no guarantee that this explains all of the user notes we've received recently. But it could explain some of them. Regards, -Rob > > Marcus > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
