Re: [webkit-dev] Upstreaming Support for W3C Sensor API
Maciej, Adam, On 03/17/2012 12:26 AM, Maciej Stachowiak wrote: Therefore, I think this work is not appropriate for the WebKit repository at this time, even as a WebCore Module. Of course, implementing the feature outside the main repository, e.g. via GitHub, is ok, and may be an opportunity to demonstrate its general usefulness. thank you for your suggestions and feedback. Going the GitHub route is an option for us, we'll keep everyone informed on tracking bug 81352. Regards, Dominik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
Hi,
On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com wrote:
This should be fixed now.
trac is down today for us.
bugs.webkit.org is also down with this error :
Software error:
Can't connect to the database.
Error: could not connect to server: Operation timed out
Is the server running on host 10.0.99.99 and accepting
TCP/IP connections on port ?
Is your database installed and up and running?
Do you have the correct username and password selected in localconfig?
Thanks.
-Bill
On Feb 29, 2012, at 5:40 AM, Ashod Nakashian wrote:
Update: trac.webkit.org was back up for a short while then died again.
(Could we the eastern-hemispherics be overloading it?)
Where previously it was not responding at all, now it's protesting...
Traceback (most recent call last):
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
line 376, in send_error
'text/html')
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/chrome.py,
line 733, in render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
line 195, in __getattr__
value = self.callbacks[name](self)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/main.py,
line 265, in _get_session
return Session(self.env, req)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 157, in __init__
self.get_session(sid)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 178, in get_session
super(Session, self).get_session(sid, authenticated)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 51, in get_session
db = self.env.get_db_cnx()
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/env.py,
line 285, in get_db_cnx
return DatabaseManager(self).get_connection()
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/api.py,
line 92, in get_connection
return self._cnx_pool.get_cnx(self.timeout or None)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
line 176, in get_cnx
return _backend.get_cnx(self._connector, self._kwargs, timeout)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
line 109, in get_cnx
cnx = connector.get_connection(**kwargs)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
line 69, in get_connection
params)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
line 185, in __init__
cnx = psycopg.connect(' '.join(dsn))
OperationalError: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
From: Ashod Nakashian ashodnakash...@yahoo.com
To: WebKit Development webkit-dev@lists.webkit.org
Sent: Wednesday, February 29, 2012 2:40 PM
Subject: [webkit-dev] trac.webkit.org is down
Hi,
As of ~20mins ago trac.webkit.org is down, webkit.org, bugs and build are
OK. Don't know who to notify so I'm spamming webkit-dev, sorry.
Who should be contacted in such cases?
-Ash
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
On 19 March 2012 22:44, Alexis Menard alexis.men...@openbossa.org wrote: Hi, On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com wrote: This should be fixed now. trac is down today for us. bugs.webkit.org is also down with this error : I'm also seeing them down with the same symptoms from my home connection in Sydney. Traceroutes appended: traceroute to bugs.webkit.org (17.254.20.233), 64 hops max, 52 byte packets 1 192-168-1-254 (192.168.1.254) 2.607 ms 0.875 ms 0.652 ms 2 syd-sot-ken2-bras2-lo20 (10.20.21.199) 18.653 ms 18.283 ms 18.731 ms 3 syd-sot-ken2-csw2-tg-3-1 (202.7.214.29) 18.890 ms 18.652 ms 18.288 ms 4 syd-sot-ken2-crt2-ge-9-0-0 (203.29.135.173) 17.809 ms 19.238 ms 18.143 ms 5 te9-1.ccr02.lax04.atlas.cogentco.com (38.104.210.53) 227.246 ms 207.515 ms 207.168 ms 6 te0-2-0-7.ccr21.lax01.atlas.cogentco.com (154.54.24.69) 207.495 ms te0-3-0-7.ccr21.lax01.atlas.cogentco.com (154.54.1.9) 208.140 ms 208.054 ms 7 te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185) 221.802 ms te9-3.mpd01.sjc01.atlas.cogentco.com (154.54.25.186) 222.440 ms te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185) 374.174 ms 8 38.104.134.70 (38.104.134.70) 220.819 ms 220.666 ms 220.254 ms 9 border1.t7-1-bbnet1.sje.pnap.net (66.151.144.4) 391.199 ms 292.140 ms 255.343 ms 10 * * * 11 * * * [etc] traceroute to trac.webkit.org (17.254.20.241), 64 hops max, 52 byte packets 1 192-168-1-254 (192.168.1.254) 3.605 ms 0.754 ms 3.930 ms 2 syd-sot-ken2-bras2-lo20 (10.20.21.199) 18.515 ms 18.350 ms 18.426 ms 3 syd-sot-ken2-csw2-tg-3-1 (202.7.214.29) 19.037 ms 18.247 ms 18.236 ms 4 syd-sot-ken2-crt1-ge-9-0-0 (202.7.171.173) 18.632 ms 18.394 ms 18.429 ms 5 ix-8-3-0-0.tcore2.lvw-losangeles.as6453.net (64.86.252.125) 200.775 ms 200.856 ms 200.622 ms 6 xe-8-0-0.edge1.losangeles9.level3.net (4.68.62.117) 201.657 ms 201.147 ms 200.371 ms 7 vlan60.csw1.losangeles1.level3.net (4.69.144.62) 203.967 ms vlan80.csw3.losangeles1.level3.net (4.69.144.190) 200.859 ms vlan90.csw4.losangeles1.level3.net (4.69.144.254) 205.358 ms 8 ae-83-83.ebr3.losangeles1.level3.net (4.69.137.41) 203.072 ms 200.655 ms ae-93-93.ebr3.losangeles1.level3.net (4.69.137.45) 200.738 ms 9 ae-3-3.ebr1.sanjose1.level3.net (4.69.132.9) 211.694 ms 211.626 ms 212.040 ms 10 ae-71-71.csw2.sanjose1.level3.net (4.69.153.6) 221.184 ms ae-61-61.csw1.sanjose1.level3.net (4.69.153.2) 211.839 ms ae-71-71.csw2.sanjose1.level3.net (4.69.153.6) 218.424 ms 11 ae-41-80.car1.sanjose2.level3.net (4.69.152.139) 212.528 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 212.445 ms ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 212.433 ms 12 * * * 13 * * * [etc] mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
On Mon, Mar 19, 2012 at 8:37 AM, Mike Lawther mikelawt...@google.comwrote: On 19 March 2012 22:44, Alexis Menard alexis.men...@openbossa.org wrote: Hi, On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com wrote: This should be fixed now. trac is down today for us. Yeah it's gotta be the server. http://www.downforeveryoneorjustme.com/trac.webkit.org It's 6:30am PST so we just need to have patience. bugs.webkit.org is also down with this error : I'm also seeing them down with the same symptoms from my home connection in Sydney. Traceroutes appended: traceroute to bugs.webkit.org (17.254.20.233), 64 hops max, 52 byte packets 1 192-168-1-254 (192.168.1.254) 2.607 ms 0.875 ms 0.652 ms 2 syd-sot-ken2-bras2-lo20 (10.20.21.199) 18.653 ms 18.283 ms 18.731 ms 3 syd-sot-ken2-csw2-tg-3-1 (202.7.214.29) 18.890 ms 18.652 ms 18.288 ms 4 syd-sot-ken2-crt2-ge-9-0-0 (203.29.135.173) 17.809 ms 19.238 ms 18.143 ms 5 te9-1.ccr02.lax04.atlas.cogentco.com (38.104.210.53) 227.246 ms 207.515 ms 207.168 ms 6 te0-2-0-7.ccr21.lax01.atlas.cogentco.com (154.54.24.69) 207.495 ms te0-3-0-7.ccr21.lax01.atlas.cogentco.com (154.54.1.9) 208.140 ms 208.054 ms 7 te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185) 221.802 ms te9-3.mpd01.sjc01.atlas.cogentco.com (154.54.25.186) 222.440 ms te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185) 374.174 ms 8 38.104.134.70 (38.104.134.70) 220.819 ms 220.666 ms 220.254 ms 9 border1.t7-1-bbnet1.sje.pnap.net (66.151.144.4) 391.199 ms 292.140 ms 255.343 ms 10 * * * 11 * * * [etc] traceroute to trac.webkit.org (17.254.20.241), 64 hops max, 52 byte packets 1 192-168-1-254 (192.168.1.254) 3.605 ms 0.754 ms 3.930 ms 2 syd-sot-ken2-bras2-lo20 (10.20.21.199) 18.515 ms 18.350 ms 18.426 ms 3 syd-sot-ken2-csw2-tg-3-1 (202.7.214.29) 19.037 ms 18.247 ms 18.236 ms 4 syd-sot-ken2-crt1-ge-9-0-0 (202.7.171.173) 18.632 ms 18.394 ms 18.429 ms 5 ix-8-3-0-0.tcore2.lvw-losangeles.as6453.net (64.86.252.125) 200.775 ms 200.856 ms 200.622 ms 6 xe-8-0-0.edge1.losangeles9.level3.net (4.68.62.117) 201.657 ms 201.147 ms 200.371 ms 7 vlan60.csw1.losangeles1.level3.net (4.69.144.62) 203.967 ms vlan80.csw3.losangeles1.level3.net (4.69.144.190) 200.859 ms vlan90.csw4.losangeles1.level3.net (4.69.144.254) 205.358 ms 8 ae-83-83.ebr3.losangeles1.level3.net (4.69.137.41) 203.072 ms 200.655 ms ae-93-93.ebr3.losangeles1.level3.net (4.69.137.45) 200.738 ms 9 ae-3-3.ebr1.sanjose1.level3.net (4.69.132.9) 211.694 ms 211.626 ms 212.040 ms 10 ae-71-71.csw2.sanjose1.level3.net (4.69.153.6) 221.184 ms ae-61-61.csw1.sanjose1.level3.net (4.69.153.2) 211.839 ms ae-71-71.csw2.sanjose1.level3.net (4.69.153.6) 218.424 ms 11 ae-41-80.car1.sanjose2.level3.net (4.69.152.139) 212.528 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 212.445 ms ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 212.433 ms 12 * * * 13 * * * [etc] mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
All services have been restored.
-Bill
On Mar 19, 2012, at 4:44 AM, Alexis Menard wrote:
Hi,
On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com
wrote:
This should be fixed now.
trac is down today for us.
bugs.webkit.org is also down with this error :
Software error:
Can't connect to the database.
Error: could not connect to server: Operation timed out
Is the server running on host 10.0.99.99 and accepting
TCP/IP connections on port ?
Is your database installed and up and running?
Do you have the correct username and password selected in localconfig?
Thanks.
-Bill
On Feb 29, 2012, at 5:40 AM, Ashod Nakashian wrote:
Update: trac.webkit.org was back up for a short while then died again.
(Could we the eastern-hemispherics be overloading it?)
Where previously it was not responding at all, now it's protesting...
Traceback (most recent call last):
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
line 376, in send_error
'text/html')
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/chrome.py,
line 733, in render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
line 195, in __getattr__
value = self.callbacks[name](self)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/main.py,
line 265, in _get_session
return Session(self.env, req)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 157, in __init__
self.get_session(sid)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 178, in get_session
super(Session, self).get_session(sid, authenticated)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 51, in get_session
db = self.env.get_db_cnx()
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/env.py,
line 285, in get_db_cnx
return DatabaseManager(self).get_connection()
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/api.py,
line 92, in get_connection
return self._cnx_pool.get_cnx(self.timeout or None)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
line 176, in get_cnx
return _backend.get_cnx(self._connector, self._kwargs, timeout)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
line 109, in get_cnx
cnx = connector.get_connection(**kwargs)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
line 69, in get_connection
params)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
line 185, in __init__
cnx = psycopg.connect(' '.join(dsn))
OperationalError: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
From: Ashod Nakashian ashodnakash...@yahoo.com
To: WebKit Development webkit-dev@lists.webkit.org
Sent: Wednesday, February 29, 2012 2:40 PM
Subject: [webkit-dev] trac.webkit.org is down
Hi,
As of ~20mins ago trac.webkit.org is down, webkit.org, bugs and build are
OK. Don't know who to notify so I'm spamming webkit-dev, sorry.
Who should be contacted in such cases?
-Ash
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
Just taking the opportunity here since it's Trac related, but the link
that is sent on a new user registration is currently wrong, just need
to do a s/www/trac/ on the URL sent.
Best regards,
Luis Felipe
On Mon, Mar 19, 2012 at 10:53 AM, William Siegrist wsiegr...@apple.com wrote:
All services have been restored.
-Bill
On Mar 19, 2012, at 4:44 AM, Alexis Menard wrote:
Hi,
On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com
wrote:
This should be fixed now.
trac is down today for us.
bugs.webkit.org is also down with this error :
Software error:
Can't connect to the database.
Error: could not connect to server: Operation timed out
Is the server running on host 10.0.99.99 and accepting
TCP/IP connections on port ?
Is your database installed and up and running?
Do you have the correct username and password selected in localconfig?
Thanks.
-Bill
On Feb 29, 2012, at 5:40 AM, Ashod Nakashian wrote:
Update: trac.webkit.org was back up for a short while then died again.
(Could we the eastern-hemispherics be overloading it?)
Where previously it was not responding at all, now it's protesting...
Traceback (most recent call last):
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
line 376, in send_error
'text/html')
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/chrome.py,
line 733, in render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
line 195, in __getattr__
value = self.callbacks[name](self)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/main.py,
line 265, in _get_session
return Session(self.env, req)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 157, in __init__
self.get_session(sid)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 178, in get_session
super(Session, self).get_session(sid, authenticated)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 51, in get_session
db = self.env.get_db_cnx()
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/env.py,
line 285, in get_db_cnx
return DatabaseManager(self).get_connection()
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/api.py,
line 92, in get_connection
return self._cnx_pool.get_cnx(self.timeout or None)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
line 176, in get_cnx
return _backend.get_cnx(self._connector, self._kwargs, timeout)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
line 109, in get_cnx
cnx = connector.get_connection(**kwargs)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
line 69, in get_connection
params)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
line 185, in __init__
cnx = psycopg.connect(' '.join(dsn))
OperationalError: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
From: Ashod Nakashian ashodnakash...@yahoo.com
To: WebKit Development webkit-dev@lists.webkit.org
Sent: Wednesday, February 29, 2012 2:40 PM
Subject: [webkit-dev] trac.webkit.org is down
Hi,
As of ~20mins ago trac.webkit.org is down, webkit.org, bugs and build are
OK. Don't know who to notify so I'm spamming webkit-dev, sorry.
Who should be contacted in such cases?
-Ash
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Luís Felipe Strano Moraes
http://www.strano.org
___
Re: [webkit-dev] trac.webkit.org is down
On Mar 19, 2012, at 9:02 AM, Luis Felipe Strano Moraes luis.str...@gmail.com wrote: Just taking the opportunity here since it's Trac related, but the link that is sent on a new user registration is currently wrong, just need to do a s/www/trac/ on the URL sent. Actually, the www link is supposed to work. Can you try again? I fixed the misconfiguration on the server. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
Well, I've already registered by using the trac subdomain, but trying it again now gives me a Bad or expired token. message, which I assume means your fix has worked. --lf On Mon, Mar 19, 2012 at 1:12 PM, William Siegrist wsiegr...@apple.com wrote: On Mar 19, 2012, at 9:02 AM, Luis Felipe Strano Moraes luis.str...@gmail.com wrote: Just taking the opportunity here since it's Trac related, but the link that is sent on a new user registration is currently wrong, just need to do a s/www/trac/ on the URL sent. Actually, the www link is supposed to work. Can you try again? I fixed the misconfiguration on the server. -Bill -- Luís Felipe Strano Moraes http://www.strano.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
Yes, that's close enough. Thanks for testing and sorry for the inconvenience. -Bill On Mar 19, 2012, at 9:25 AM, Luis Felipe Strano Moraes luis.str...@gmail.com wrote: Well, I've already registered by using the trac subdomain, but trying it again now gives me a Bad or expired token. message, which I assume means your fix has worked. --lf On Mon, Mar 19, 2012 at 1:12 PM, William Siegrist wsiegr...@apple.com wrote: On Mar 19, 2012, at 9:02 AM, Luis Felipe Strano Moraes luis.str...@gmail.com wrote: Just taking the opportunity here since it's Trac related, but the link that is sent on a new user registration is currently wrong, just need to do a s/www/trac/ on the URL sent. Actually, the www link is supposed to work. Can you try again? I fixed the misconfiguration on the server. -Bill -- Luís Felipe Strano Moraes http://www.strano.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] number of wrapped objects in JSC
Hey, I intend to add a graph in the inspector's timeline panel that shows the number of global handles for V8. The V8 bindings use maps for WebCore objects to global handles to V8 wrapper objects. A steady increase of global handles is often a sign of a memory leak within v8 bindings. My question to the JSC folks is, is there a similar counter in JSC? I.e. something that corresponds to the number of wrapped WebCore objects (and potentially other objects that are kept alive without necessarily being reachable from javascript)? thanks -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] number of wrapped objects in JSC
I intend to add a graph in the inspector's timeline panel that shows the number of global handles for V8. The V8 bindings use maps for WebCore objects to global handles to V8 wrapper objects. A steady increase of global handles is often a sign of a memory leak within v8 bindings. Are you sure that all wrappers go into a map? What about wrappers for ScriptWrappable objects? My question to the JSC folks is, is there a similar counter in JSC? I.e. something that corresponds to the number of wrapped WebCore objects (and potentially other objects that are kept alive without necessarily being reachable from javascript)? You could read the length of JSC::HandleHeap::m_weakList. Since that's an expensive operation, I'd suggest computing the length during garbage collection and then caching it. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] number of wrapped objects in JSC
On Mon, Mar 19, 2012 at 9:47 PM, Geoffrey Garen gga...@apple.com wrote: I intend to add a graph in the inspector's timeline panel that shows the number of global handles for V8. The V8 bindings use maps for WebCore objects to global handles to V8 wrapper objects. A steady increase of global handles is often a sign of a memory leak within v8 bindings. Are you sure that all wrappers go into a map? What about wrappers for ScriptWrappable objects? That's right, not all objects are kept in maps, but all objects have a global handle somewhere. My question to the JSC folks is, is there a similar counter in JSC? I.e. something that corresponds to the number of wrapped WebCore objects (and potentially other objects that are kept alive without necessarily being reachable from javascript)? You could read the length of JSC::HandleHeap::m_weakList. Since that's an expensive operation, I'd suggest computing the length during garbage collection and then caching it. awesome, thanks -jochen Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Upstreaming Support for W3C Sensor API
Maciej, I've been trying to find a home for Ink data for some time. The one inroad I've made was to make the case in the touch events 2 proposal: https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html Is that what I should move forward with, with Ink? I've been following the Sensor API because the structure works for the raw data of a pen, monitoring pen pressure, tilt and rotation, resolution and other items, to the standard serialization format now recommended by the W3C: Raw sensor data: http://www.wacomeng.com/web/WebPluginReleaseNotes.htm#_Toc293867182 Sensor API: http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html Serialization format: http://www.w3.org/TR/InkML/ The whole of the Sensor API can be serialized without losing information or breaking the file; it allows arbitrary units in addition to the base: http://www.w3.org/TR/InkML/#units The Gamepad API itself has shown resolution issues: http://code.google.com/p/chromium/issues/detail?id=79050 Do we want to move forward with device-specific APIs, such as Gamepad and Touch Events 2, or do we want to have a more general mechanism? The Sensor API is a more low level API than the gloss and sheen of Touch 2 or Gamepad. When you've got a high fidelity sensor, such as a Wacom pen, those things can sure burst a whole lot of information. Wikipedia says up to 200 times per second. That's where the Sensor API could work well for a very reasonable use case (high fidelity ink). -Charles On 3/16/2012 3:26 PM, Maciej Stachowiak wrote: I think this feature is pretty far out relative to WebKit project goals, even independent of spec maturity level. We've had controversy (though ultimately tentative agreement on adding) APIs for hardware found in some but not all classes of mainstream hardware that runs a browser. For example, Vibration API was pretty specific to the phone. Gamepad API seems specific to game consoles or those relatively rate PCs that have a game pad attached. The types of sensors in this API (Temperature, Air Pressure, Humidity, Magnetic Field Strength...) strike me as not common I/O devices on any mainstream class of hardware. Therefore I would class this whole feature area as experimental and not in line with WebKit project goals. Therefore, I think this work is not appropriate for the WebKit repository at this time, even as a WebCore Module. Of course, implementing the feature outside the main repository, e.g. via GitHub, is ok, and may be an opportunity to demonstrate its general usefulness. Regards, Maciej On Mar 16, 2012, at 2:15 PM, Adam Barth wrote: Historically, the WebKit project hasn't had the warmest relationship with the DAP working group, and we've tended to be conservative about which DAP APIs we merge into trunk. The Sensor API appears to be fairly early in its lifecycle. As far as I can tell, it hasn't even reached FPWD, which means, among other things, that the W3C patent process hasn't started. These factors lead me to think that we should wait a bit before landing the feature in trunk. You might consider implementing this feature as a WebCore Module https://trac.webkit.org/wiki/Modules. If you go that route, the implementation should be fairly loosely coupled with the rest of WebCore, which means implementing the feature first on GitHub (a la https://trac.webkit.org/wiki/UsingGitHub) might be a good choice. This approach will give you a chance to experiment with an implementation and receive feedback from the WebKit community without being blocked on merging your feature into trunk. Adam 2012/3/16 Adam Barthaba...@webkit.org: The specification appears to be here: http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html Has this specification reached FPWD yet? http://www.w3.org/TR/sensor/ returns a 404. Adam 2012/3/16 Dominik Röttschesdominik.rottsc...@linux.intel.com: Hello webkit-dev, We would like to upstream our implementation of W3C Sensor API [1]. As we are aware that this is a young specification, we propose to have it default #ifdef-disabled. However, we believe it could be useful for certain ports or useful for being accessed by Chrome extensions. Your feedback is welcome. For reference, we created meta bug https://bugs.webkit.org/show_bug.cgi?id=81352 Regards, Dominik Röttsches ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Magic Iframe removal proposed
Hi, There is a patch posted https://bugs.webkit.org/show_bug.cgi?id=81590 for removal of the 'magic iframe' feature. This is the ability to move 'live' iframe from one page to another w/o unloading it. If you have interest or ideas about this feature, please reply. HISTORY This feature was added 2 years ago (bug herehttps://bugs.webkit.org/show_bug.cgi?id=32848). It was intended as a shared app context for complex apps that span several pages. In case when random set of pages is closed, the surviving iframe could be passed between remaining pages and serve as 'app state'. This behavior is somewhat described in HTML5 spechttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element: Removing an iframe from a Document does not cause its browsing context to be discarded. Indeed, an iframe's browsing context can survive its original parent Document if its iframe is moved to another Document. All non-WebKit browsers don't have this and always unload the iframe when it is disconnected form the document. PROBLEMS We did have quite a few issues with this mechanism. The root of the problem seems to be that traditionally, multiple 'permissions' and 'live objects' are associated with a top-level page, or a top frame of some kind, instead of being associated with each Frame. Even HTML specifications often formulate the scope of things like permissions in terms of a page - for example, geo permissions are computed based on the origin of the page. When an iframe is transferred from one page to another, it may enter a different set of permissions while already performing operations authorized before. Association with the top-level page is also used to determine which one should show modal UI for HTTP Auth, per-origin permissions, or certificate issues for example. As a result, we had quite a few bugs popping up (and fixed). WHY REMOVE This is somewhat obscure feature of the platform. Only a few apps that we knew used the feature. Most developers, both app and webkit kind, don't even know about it. When new mechanisms/APIs are implemented, a lot of objects get associated with Page (WebView) level and they are almost 'automatically' broken in case of live iframe transfer because once old page closes, it destroys the objects with lifetimes scoped by it. This makes it somewhat dangerous and difficult to support. The benefits that it gives to the big multi-page applications do not seem to warrant the actual complexity of maintaining this feature. Other browsers never implemented the feature, siting difficult design due to various thorny security issues as well. This is potentially a compatibility issue for sites that use document.adoptNode(iframe) to ensure live transfer of an iframe from one page to another. In the future, if there will be sufficient need, it is possible to design a 'shared module' feature that would explicitly deal with various security/lifetime boundaries. Please let us know what you think. Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Magic Iframe removal proposed
Hi Dmitry. Two thoughts on this: (1) If we remove this feature, are Chromium/GMail developers going to re-request the other shared document features that this feature subsumed? Or are y'all now convinced that shared document is, in general, not a good idea? The reason I ask this is that, given your description, I see some problems with the shared iframe feature, but I still think it's much better than previously proposed alternatives. (2) I think you should share your data with the relevant standards bodies, and suggest a change to the HTML5 spec, if you haven't done so already. I wouldn't want to remove this feature just to add it back later for the sake of spec compliance. Thanks, Geoff On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted for removal of the 'magic iframe' feature. This is the ability to move 'live' iframe from one page to another w/o unloading it. If you have interest or ideas about this feature, please reply. HISTORY This feature was added 2 years ago (bug here). It was intended as a shared app context for complex apps that span several pages. In case when random set of pages is closed, the surviving iframe could be passed between remaining pages and serve as 'app state'. This behavior is somewhat described in HTML5 spec: Removing an iframe from a Document does not cause its browsing context to be discarded. Indeed, an iframe's browsing context can survive its original parent Document if its iframe is moved to another Document. All non-WebKit browsers don't have this and always unload the iframe when it is disconnected form the document. PROBLEMS We did have quite a few issues with this mechanism. The root of the problem seems to be that traditionally, multiple 'permissions' and 'live objects' are associated with a top-level page, or a top frame of some kind, instead of being associated with each Frame. Even HTML specifications often formulate the scope of things like permissions in terms of a page - for example, geo permissions are computed based on the origin of the page. When an iframe is transferred from one page to another, it may enter a different set of permissions while already performing operations authorized before. Association with the top-level page is also used to determine which one should show modal UI for HTTP Auth, per-origin permissions, or certificate issues for example. As a result, we had quite a few bugs popping up (and fixed). WHY REMOVE This is somewhat obscure feature of the platform. Only a few apps that we knew used the feature. Most developers, both app and webkit kind, don't even know about it. When new mechanisms/APIs are implemented, a lot of objects get associated with Page (WebView) level and they are almost 'automatically' broken in case of live iframe transfer because once old page closes, it destroys the objects with lifetimes scoped by it. This makes it somewhat dangerous and difficult to support. The benefits that it gives to the big multi-page applications do not seem to warrant the actual complexity of maintaining this feature. Other browsers never implemented the feature, siting difficult design due to various thorny security issues as well. This is potentially a compatibility issue for sites that use document.adoptNode(iframe) to ensure live transfer of an iframe from one page to another. In the future, if there will be sufficient need, it is possible to design a 'shared module' feature that would explicitly deal with various security/lifetime boundaries. Please let us know what you think. Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Magic Iframe removal proposed
On Mon, Mar 19, 2012 at 6:09 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitry. Two thoughts on this: (1) If we remove this feature, are Chromium/GMail developers going to re-request the other shared document features that this feature subsumed? Or are y'all now convinced that shared document is, in general, not a good idea? On a contrary, 'shared application state' could be a good idea, however this particular way to implement it unfortunately is very difficult to get right. There are no Google applications that use this feature currently, and there is understanding of the costs involved. There is a possibility that some other idea can both address the potential need and be reliably implementable at the same time. Workers, for example, are a good case of limiting the surface that also limits design/maintenance costs. Perhaps something similar can be proposed for shared state. However, there was a discussion in Chromium and it appears that ongoing design and maintenance of magic iframe is not worth the benefit the feature provides for the applications. The reason I ask this is that, given your description, I see some problems with the shared iframe feature, but I still think it's much better than previously proposed alternatives. (2) I think you should share your data with the relevant standards bodies, and suggest a change to the HTML5 spec, if you haven't done so already. I wouldn't want to remove this feature just to add it back later for the sake of spec compliance. Good suggestion, will do. Just wanted to give WebKit community a heads-up... Thanks, Geoff On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted https://bugs.webkit.org/show_bug.cgi?id=81590for removal of the 'magic iframe' feature. This is the ability to move 'live' iframe from one page to another w/o unloading it. If you have interest or ideas about this feature, please reply. HISTORY This feature was added 2 years ago (bug herehttps://bugs.webkit.org/show_bug.cgi?id=32848). It was intended as a shared app context for complex apps that span several pages. In case when random set of pages is closed, the surviving iframe could be passed between remaining pages and serve as 'app state'. This behavior is somewhat described in HTML5 spechttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element: Removing an iframe from a Document does not cause its browsing context to be discarded. Indeed, an iframe's browsing context can survive its original parent Document if its iframe is moved to another Document. All non-WebKit browsers don't have this and always unload the iframe when it is disconnected form the document. PROBLEMS We did have quite a few issues with this mechanism. The root of the problem seems to be that traditionally, multiple 'permissions' and 'live objects' are associated with a top-level page, or a top frame of some kind, instead of being associated with each Frame. Even HTML specifications often formulate the scope of things like permissions in terms of a page - for example, geo permissions are computed based on the origin of the page. When an iframe is transferred from one page to another, it may enter a different set of permissions while already performing operations authorized before. Association with the top-level page is also used to determine which one should show modal UI for HTTP Auth, per-origin permissions, or certificate issues for example. As a result, we had quite a few bugs popping up (and fixed). WHY REMOVE This is somewhat obscure feature of the platform. Only a few apps that we knew used the feature. Most developers, both app and webkit kind, don't even know about it. When new mechanisms/APIs are implemented, a lot of objects get associated with Page (WebView) level and they are almost 'automatically' broken in case of live iframe transfer because once old page closes, it destroys the objects with lifetimes scoped by it. This makes it somewhat dangerous and difficult to support. The benefits that it gives to the big multi-page applications do not seem to warrant the actual complexity of maintaining this feature. Other browsers never implemented the feature, siting difficult design due to various thorny security issues as well. This is potentially a compatibility issue for sites that use document.adoptNode(iframe) to ensure live transfer of an iframe from one page to another. In the future, if there will be sufficient need, it is possible to design a 'shared module' feature that would explicitly deal with various security/lifetime boundaries. Please let us know what you think. Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Magic Iframe removal proposed
I support the removal. I've seen quite a few security bugs caused by this feature. Please make sure the spec changes as Geoff pointed out. - Ryosuke On Mon, Mar 19, 2012 at 5:51 PM, Dmitry Titov dim...@chromium.org wrote: Hi, There is a patch posted https://bugs.webkit.org/show_bug.cgi?id=81590for removal of the 'magic iframe' feature. This is the ability to move 'live' iframe from one page to another w/o unloading it. If you have interest or ideas about this feature, please reply. HISTORY This feature was added 2 years ago (bug herehttps://bugs.webkit.org/show_bug.cgi?id=32848). It was intended as a shared app context for complex apps that span several pages. In case when random set of pages is closed, the surviving iframe could be passed between remaining pages and serve as 'app state'. This behavior is somewhat described in HTML5 spechttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element: Removing an iframe from a Document does not cause its browsing context to be discarded. Indeed, an iframe's browsing context can survive its original parent Document if its iframe is moved to another Document. All non-WebKit browsers don't have this and always unload the iframe when it is disconnected form the document. PROBLEMS We did have quite a few issues with this mechanism. The root of the problem seems to be that traditionally, multiple 'permissions' and 'live objects' are associated with a top-level page, or a top frame of some kind, instead of being associated with each Frame. Even HTML specifications often formulate the scope of things like permissions in terms of a page - for example, geo permissions are computed based on the origin of the page. When an iframe is transferred from one page to another, it may enter a different set of permissions while already performing operations authorized before. Association with the top-level page is also used to determine which one should show modal UI for HTTP Auth, per-origin permissions, or certificate issues for example. As a result, we had quite a few bugs popping up (and fixed). WHY REMOVE This is somewhat obscure feature of the platform. Only a few apps that we knew used the feature. Most developers, both app and webkit kind, don't even know about it. When new mechanisms/APIs are implemented, a lot of objects get associated with Page (WebView) level and they are almost 'automatically' broken in case of live iframe transfer because once old page closes, it destroys the objects with lifetimes scoped by it. This makes it somewhat dangerous and difficult to support. The benefits that it gives to the big multi-page applications do not seem to warrant the actual complexity of maintaining this feature. Other browsers never implemented the feature, siting difficult design due to various thorny security issues as well. This is potentially a compatibility issue for sites that use document.adoptNode(iframe) to ensure live transfer of an iframe from one page to another. In the future, if there will be sufficient need, it is possible to design a 'shared module' feature that would explicitly deal with various security/lifetime boundaries. Please let us know what you think. Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Magic Iframe removal proposed
I have no immediate objection to removing the shared iframe feature since, as you say, it's a source of problems, very few apps use it, and no apps require it. It's great that we did this feature through a pre-existing web technology, so we discovered its problems, and can now remove it, without creating a huge API surface area burden along the way. On a contrary, 'shared application state' could be a good idea, however this particular way to implement it unfortunately is very difficult to get right. There are no Google applications that use this feature currently, and there is understanding of the costs involved. There is a possibility that some other idea can both address the potential need and be reliably implementable at the same time. Workers, for example, are a good case of limiting the surface that also limits design/maintenance costs. Perhaps something similar can be proposed for shared state. However, there was a discussion in Chromium and it appears that ongoing design and maintenance of magic iframe is not worth the benefit the feature provides for the applications. This doesn't sound so good to me. The main problem you identified with shared iframes -- the fact that permissions and live objects are typically associated with a single top-level page, and can get confused in the context of sharing between pages -- sounds like a problem with sharing, and not a problem with iframes as the mechanism for sharing. I don't support Sharing is hard and nobody uses it, therefore let's add sharing through workers. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Ambiguity in the style guide
Hello WebKittens, While I am loathe to take up list space with another style guide threads, Eric Seidel recently pointed out to me some ambiguities in the style guide at https://bugs.webkit.org/show_bug.cgi?id=81602. Namely sections three and four of the #include Statements section. The relevant sections are: Other #include statements should be in sorted order (case sensitive, as done by the command-line sort tool or the Xcode sort selection command). Don't bother to organize them in a logical order. and Includes of system headers must come after includes of other headers. The ambiguities are: 1. Are WTF and other WebKit headers included like #include project/foo.h considered system headers? 2. Exactly what sort order is desired (e.g. capitals before lower case)? Hopefully this isn't seen as just a pedantic exercise. I'm interested in answering these questions so that I can modify check-webkit-style to catch these errors. On the other hand, if the exact nature of these rules is seen as unimportant, perhaps we could just remove that part of the guide. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
