[chromium-dev] buildbot failure in Chromium on Modules XP, revision 35068
Automatically closing tree for net_unittests on Modules XP http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP/builds/21055 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP --= Automatically closing tree for net_unittests on Modules XP =-- Revision: 35068 Blame list: viettrung...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Link error with chromium on ubuntu 9.10
On Sat, Dec 19, 2009 at 5:39 PM, Jacob Mandelson ja...@mandelson.org wrote:
Probably the OOM killer. Chrome takes a very large amount of memory to link.
You can add some swap, or trade a lot of link-time memory for a little startup
delay by building shared. You can do that by putting this in your
~/.gyp/include.gypi:
{'variables': {
'library': 'shared_library',
}}
Does this build still work? Last time I tried it it was broken again
(something in v8...).
I think you need somewhere around 2gb of RAM + some swap to build.
I note the WebKitGtk hackers (who are on relatively weak laptops) will
actually close down most of the software they're using when it comes
time to link, to make more memory available. :~(
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Setting global preferences/settings in code
On Sat, Dec 19, 2009 at 9:32 PM, cpu c...@chromium.org wrote: Yes, the MasterPreferences is what we use so far. It is just a json file in a particular path. I am not sure if we have enabled this for the linux build. It hasn't. See browser_main.cc around line 540, the part that mentions ProcessMasterPreferences: http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob;f=chrome/browser/browser_main.cc;h=ff1d17d7277b5df9a9e1d901adaf326ee6c2c6ff;hb=HEAD#l539 You could probably follow the Windows implementation of ProcessMasterPreferences (see first_run_win) to make a Linux one, but it will of course be rather different. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on XP Tests (dbg)(1), revision 35069
Automatically closing tree for unit_tests on XP Tests (dbg)(1) http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests%20%28dbg%29%281%29/builds/17109 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests%20%28dbg%29%281%29 --= Automatically closing tree for unit_tests on XP Tests (dbg)(1) =-- Revision: 35069 Blame list: jer...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] repeated form submit broken in chrome
I have three scenarios that seem to suggest a bug in chrome for form
submission, please see example code below
1. form.submit with a named target opens a new tab the first time with
the submitted data.
subsequent attempts fail to open a new tab (or pull in the submitted
data to the pre-existing tab)
2. form.submit with target=foobar opens a new tab the first time
subsequent attempts post the new submission data to the pre-existing
tab, as it should.
if we close the tab.. then submit again, it fails to open a new tab.
3. form.submit with target=_blank opens a new tab the first time.
form.submit with no target successfully downloads a file.
form.submit with target=_blank now successfully opens a new tab! (the
same is true if target=foobar both times and we close the tab).
Are there any known issues with chrome form submission? It all works
correctly in safari, firefox and ie.
Sincerely,
Alexander
Example code:
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=content-type content=text/
html;charset=utf-8 /
script language='JavaScript'
function submitForm() {
form = document.getElementById('myform');
form.action = http://www.google.com/search;;
form.target = 'google';
form.submit();
}
function downloadForm() {
form = document.getElementById('myform');
form.action = 'file.csv';
form.target = 'self';
form.submit();
}
/script
/head
body
form id=myform method='GET'
input type='hidden' name='q' value='git5' /
/form
a href=# onclick='downloadForm()'downloada
a href=# onclick='submitForm()'submita
/body
/html
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] repeated form submit broken in chrome
Sounds buggy to me. Please log this at http://new.crbug.com/
Thanks!
-Darin
On Sun, Dec 20, 2009 at 9:49 PM, aggubin aggu...@gmail.com wrote:
I have three scenarios that seem to suggest a bug in chrome for form
submission, please see example code below
1. form.submit with a named target opens a new tab the first time with
the submitted data.
subsequent attempts fail to open a new tab (or pull in the submitted
data to the pre-existing tab)
2. form.submit with target=foobar opens a new tab the first time
subsequent attempts post the new submission data to the pre-existing
tab, as it should.
if we close the tab.. then submit again, it fails to open a new tab.
3. form.submit with target=_blank opens a new tab the first time.
form.submit with no target successfully downloads a file.
form.submit with target=_blank now successfully opens a new tab! (the
same is true if target=foobar both times and we close the tab).
Are there any known issues with chrome form submission? It all works
correctly in safari, firefox and ie.
Sincerely,
Alexander
Example code:
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=content-type content=text/
html;charset=utf-8 /
script language='JavaScript'
function submitForm() {
form = document.getElementById('myform');
form.action = http://www.google.com/search;;
form.target = 'google';
form.submit();
}
function downloadForm() {
form = document.getElementById('myform');
form.action = 'file.csv';
form.target = 'self';
form.submit();
}
/script
/head
body
form id=myform method='GET'
input type='hidden' name='q' value='git5' /
/form
a href=# onclick='downloadForm()'downloada
a href=# onclick='submitForm()'submita
/body
/html
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Recovering from browser crashes
It's already been said, but this was something we considered in the very beginning. There's a lot of state in the browser buried in classes that are not designed to be restarted. We have had enough trouble resetting state in the browser corresponding to a tab that crashed and reloaded. One thing that might help is to factor the browser process into two. If we can carve off a meaningful chunk, perhaps we can also design that chunk to be restartable. It might help to look at what parts of the browser process have had the most crash bugs. Maybe anything that doesn't happen on the UI thread (gross approximation)? -Darin On Fri, Dec 18, 2009 at 9:13 AM, Adam Barth aba...@chromium.org wrote: Currently our multiprocess architecture lets the browser keep going when one of its tabs crash, but why can't we keep the tabs going when the browser crashes? At a high level, imagine we had a watchdog process that kept track, essentially, of the tab model and the navigation controllers. When the browser process crashes, we could use this information to do something like session restore, but instead of reloading the tabs from the network, we could re-attach to the tab processes that are already running. There's some trickiness revolving around in-flight requests from the renderer processes to the browser process (such as synchronous XMLHttpRequests), but that seems like a solvable problem. Basically, the approach would be to respond to any in-flight requests with failure messages. Thoughts? Adam -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Recovering from browser crashes
And in that case we can hopefully use this for session restore too. -Ben On Sun, Dec 20, 2009 at 10:20 PM, Darin Fisher da...@chromium.org wrote: It's already been said, but this was something we considered in the very beginning. There's a lot of state in the browser buried in classes that are not designed to be restarted. We have had enough trouble resetting state in the browser corresponding to a tab that crashed and reloaded. One thing that might help is to factor the browser process into two. If we can carve off a meaningful chunk, perhaps we can also design that chunk to be restartable. It might help to look at what parts of the browser process have had the most crash bugs. Maybe anything that doesn't happen on the UI thread (gross approximation)? -Darin On Fri, Dec 18, 2009 at 9:13 AM, Adam Barth aba...@chromium.org wrote: Currently our multiprocess architecture lets the browser keep going when one of its tabs crash, but why can't we keep the tabs going when the browser crashes? At a high level, imagine we had a watchdog process that kept track, essentially, of the tab model and the navigation controllers. When the browser process crashes, we could use this information to do something like session restore, but instead of reloading the tabs from the network, we could re-attach to the tab processes that are already running. There's some trickiness revolving around in-flight requests from the renderer processes to the browser process (such as synchronous XMLHttpRequests), but that seems like a solvable problem. Basically, the approach would be to respond to any in-flight requests with failure messages. Thoughts? Adam -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
