You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2013/09/04 22:47:13 UTC
Another test of the download page on Browsershots.com
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)
The IE versions all give the same script 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?
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 09/09/2013 08:50 PM, schrieb Rob Weir:
> On Mon, Sep 9, 2013 at 2:32 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 09/09/2013 07:50 PM, schrieb Rob Weir:
>>
>>> On Fri, Sep 6, 2013 at 3:33 AM, Marcus (OOo)<ma...@wtnet.de> wrote:
>>>>
>>>> Am 09/06/2013 03:18 AM, schrieb Rob Weir:
>>>>
>>>>> On Thu, Sep 5, 2013 at 4:32 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Am 09/05/2013 10:20 PM, schrieb Rob Weir:
>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 09/05/2013 12:20 AM, schrieb Rob Weir:
>>>>>>>>
>>>>>>>>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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.
Sure, but let's assume it was the solution. If not, I'm pretty sure we
will get new mails from our users. ;-)
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by Rob Weir <ro...@apache.org>.
On Mon, Sep 9, 2013 at 2:32 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 09/09/2013 07:50 PM, schrieb Rob Weir:
>
>> On Fri, Sep 6, 2013 at 3:33 AM, Marcus (OOo)<ma...@wtnet.de> wrote:
>>>
>>> Am 09/06/2013 03:18 AM, schrieb Rob Weir:
>>>
>>>> On Thu, Sep 5, 2013 at 4:32 PM, Marcus (OOo)<ma...@wtnet.de>
>>>> wrote:
>>>>>
>>>>>
>>>>> Am 09/05/2013 10:20 PM, schrieb Rob Weir:
>>>>>
>>>>>> On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 09/05/2013 12:20 AM, schrieb Rob Weir:
>>>>>>>
>>>>>>>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 09/09/2013 07:50 PM, schrieb Rob Weir:
> On Fri, Sep 6, 2013 at 3:33 AM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 09/06/2013 03:18 AM, schrieb Rob Weir:
>>
>>> On Thu, Sep 5, 2013 at 4:32 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>>>>
>>>> Am 09/05/2013 10:20 PM, schrieb Rob Weir:
>>>>
>>>>> On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Am 09/05/2013 12:20 AM, schrieb Rob Weir:
>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by Rob Weir <ro...@apache.org>.
On Fri, Sep 6, 2013 at 3:33 AM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 09/06/2013 03:18 AM, schrieb Rob Weir:
>
>> On Thu, Sep 5, 2013 at 4:32 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>>>
>>> Am 09/05/2013 10:20 PM, schrieb Rob Weir:
>>>
>>>> On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)<ma...@wtnet.de>
>>>> wrote:
>>>>>
>>>>>
>>>>> Am 09/05/2013 12:20 AM, schrieb Rob Weir:
>>>>>
>>>>>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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
It says the final semi-colon is fine, but the trailing comma is no.
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.
-Rob
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 09/06/2013 03:18 AM, schrieb Rob Weir:
> On Thu, Sep 5, 2013 at 4:32 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 09/05/2013 10:20 PM, schrieb Rob Weir:
>>
>>> On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>>>>
>>>> Am 09/05/2013 12:20 AM, schrieb Rob Weir:
>>>>
>>>>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by Rob Weir <ro...@apache.org>.
On Thu, Sep 5, 2013 at 4:32 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 09/05/2013 10:20 PM, schrieb Rob Weir:
>
>> On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>>>
>>> Am 09/05/2013 12:20 AM, schrieb Rob Weir:
>>>
>>>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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.
-Rob
> Thanks
>
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 09/05/2013 10:20 PM, schrieb Rob Weir:
> On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 09/05/2013 12:20 AM, schrieb Rob Weir:
>>
>>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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.
Thanks
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by Rob Weir <ro...@apache.org>.
On Wed, Sep 4, 2013 at 6:46 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 09/05/2013 12:20 AM, schrieb Rob Weir:
>
>> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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,
but we're blocked either way, because of robots.txt on staging:
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.
-Rob
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 09/05/2013 12:20 AM, schrieb Rob Weir:
> On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo)<ma...@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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by Rob Weir <ro...@apache.org>.
On Wed, Sep 4, 2013 at 5:37 PM, Marcus (OOo) <ma...@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.
> 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,
>
>> 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.
>
>> 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?
-Rob
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Another test of the download page on Browsershots.com
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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. ;-)
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.
> 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.
> 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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org