For reference, here now is the .reg file that will also work with
previously associated files all solved now!
Windows Registry Editor Version 5.00
[-HKEY_LOCAL_MACHINE\Software\Classes\.myextension]
[-HKEY_CURRENT_USER\Software\Classes\.myextension]
For the record, I build on win7 (both x86 and x64) on vs2008 without
problem here.
M-A
On Tue, Oct 6, 2009 at 9:21 PM, vha14 vuh...@gmail.com wrote:
Still having the same issue after following John's suggestions. Being
forced to use a separate cygwin's bash.exe.
On Oct 2, 12:16 am,
A fix just got in this morning that will hopefully fix recent buildbot
spamming habits. It'll still send emails to chromium-dev@ but only when it's
actually closing the tree. There was a mismatch between the rules used to
close the tree and the rules used to send an email. I'll let you guess which
I've spent some time banging my head against this issue on Mac where
when we open a ton of tabs at the same time (15+, eg, mashing down
cmd-t or opening all bookmarks as tabs) it looks janky because the
tabs animate independently. As a result, we end up with the surfacing
tabs stuck at various
On Tue, Oct 6, 2009 at 10:52 PM, Darin Fisher da...@chromium.org wrote:
If a test sometimes crashes or hangs, it'll still be disabled, right?
Yes.
But if it's a ui_tests that crashes chrome.exe (and not ui_tests.exe), we
can still mark it as flaky.
Nicolas
-darin
On Tue, Oct 6, 2009 at
On Tue, Oct 6, 2009 at 6:49 PM, John Abd-El-Malek j...@chromium.org wrote:
It's about getting rid of nasty problems like the browser process crashing
every startup because of a corrupt database and decreasing browser process
crashes in general.
I am pretty sure that the sqlite wrapper and
On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 11:09 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Tue, Oct 06, 2009 at 09:19:49PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
Just a while before one of my tabs (GMail) started using a lot of CPU time
(67% while I was compiling in the background). The browser and the system
were responsive at all times, but processing power was wasted.
We have a warning dialog for hanged renderers offering to kill them. What do
you think
Because we have different frontend codebases on different platforms,
it's important that we strive to maintain feature parity between them.
For this reason whenever we implement a modification to the UI in
substance (e.g. add a feature, change a behavior) we should make sure
to file a bug for the
Yes, please! However, I would get that dialog about 1000 times a day:
http://crbug.com/22948
Linus
On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote:
Just a while before one of my tabs (GMail) started using a lot of CPU time
(67% while I was compiling in the
FWIW, on extensions, what we have been finding works is to file
separate bugs for each platform's UI implementation. It is just too
much code to track with one bug. You end up with these mega bugs that
never close.
We label each bug OS-whatever the case may be
- a
On Wed, Oct 7, 2009 at 10:01
That sounds like the best plan to me. This way there can be separate owners.
-Ben
On Wed, Oct 7, 2009 at 10:04 AM, Aaron Boodman a...@chromium.org wrote:
FWIW, on extensions, what we have been finding works is to file
separate bugs for each platform's UI implementation. It is just too
much
maybe instead of a dialog, we can have some kind of a non-modal badness
indicator?-darin
On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote:
Just a while before one of my tabs (GMail) started using a lot of CPU time
(67% while I was compiling in the background). The
Something like yes! Maybe not a dialog, as I use things that peg my
CPU (games) somewhat frequently.
One idea we toyed with was marking such tabs as 'on fire' (icon or
color), so at least there was a visual indication. I think this would
be a good starting point before anything more obtrusive
Also, it would be great if you found someone willing to implement the
modification on other platforms if you're not going to do it yourself.
This helps to get feedback early from other platforms (where the
modification might not make sense) and it makes sure the bug doesn't
sit there without an
+1 to glowing hot idea!
:DG
On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote:
Something like yes! Maybe not a dialog, as I use things that peg my
CPU (games) somewhat frequently.
One idea we toyed with was marking such tabs as 'on fire' (icon or
color), so at least
http://tinderbox.mozilla.org/1afi003r.gif
On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote:
Something like yes! Maybe not a dialog, as I use things that peg my
CPU (games) somewhat frequently.
One idea we toyed with was marking such tabs as 'on fire' (icon or
color), so
It's better to be non-animated. Remember,ichrome is using too much CPU
already. Second; the user is doing something, he doesn't want to be
distracted with information unrelated to his current task. If the user
finds himself waiting on his current tab, his eyes will probably see a
tab being
You could replace the favicon with a spinning clock or something. It
might also be interesting to provide indicators for high memory usage
(or perhaps if the recent memory growth is high), or IPC issues.
Then again, many users might prefer not to have their tabs attracting
attention needlessly.
We had also discussed putting icons indicating audio into tabs. That
sounds crowded with icons, though: imaginably a game could have
facicon, Unicode symbols, CPU load, audio, and the x displayed. I
worry there just aren't enough pixels to display all the relevant
information.
On Wed, Oct 7,
Hey Guys,
what is difference between these releases 3.0.190.2 3.0.195.25
i can get to SVN source tree to read access for code tree
3.0.190.2 using the following svn repository url
http://src.chromium.org/svn/releases/3.0.190.2/src/
i want to make sure i am getting the latest stable source
The latest source is in trunk, not a specific release branch.
-- Elliot
On Tue, Oct 6, 2009 at 12:34 PM, Amit Kishnani akish...@adobe.com wrote:
Hey Guys,
what is difference between these releases 3.0.190.2 3.0.195.25
i can get to SVN source tree to read access for code tree
3.0.190.2
Most kiosk applications I have developed never leave their designated
pages anyway. There are no 'offsite' links or anything. Thus the
content is fully controlled. Downloads would not have to be disabled
for me. The only 2 key options I would personally want for a kiosk
mode, are fullscreen (not
I'm not convinced that we should bother users with this kind of stuff. If an
advanced user want to see what's consuming resources, they can open the task
manager.
If we want this for debugging, perhaps it should live behind a flag. It
would be cool if some kind combo of dev tools + extensions
It'd be nice to have a non-distracting visual indicator, but to play the
devil's advocate...
What about intentionally CPU intensive sites that use canvas, video,
WebGL?
What about scenarios where it's a plugin that's gone haywire?
Could this be accomplished by an extension that displays a little
Hey Elliot,
thanks for quick turnaround.
the trunk (svn) : http://src.chromium.org/svn/trunk/src/chrome/VERSION is
MAJOR=4
MINOR=0
BUILD=222
PATCH=1
but I am looking for stable channel - 3.0.195.125 release instead of dev
channel, please let me know if there is svn repository link with that
On Wed, Oct 7, 2009 at 11:34 AM, Albert J. Wong (王重傑)
ajw...@chromium.orgwrote:
We just noticed that the Chromium Helper.app cannot locate the ffmpeg
binaries (libav*.dylib) in Mac Chromium. This leads to the video feature
being disabled. :(
Where should the ffmpeg binaries go? Should they
We just noticed that the Chromium Helper.app cannot locate the ffmpeg
binaries (libav*.dylib) in Mac Chromium. This leads to the video feature
being disabled. :(
Where should the ffmpeg binaries go? Should they be put alongside the
binary in the Chromium Helper.app/Contents/MacOS? If we do
On Wed, Oct 7, 2009 at 11:36 AM, Andrew Scherkus scher...@chromium.orgwrote:
On Wed, Oct 7, 2009 at 11:34 AM, Albert J. Wong (王重傑) ajw...@chromium.org
wrote:
We just noticed that the Chromium Helper.app cannot locate the ffmpeg
binaries (libav*.dylib) in Mac Chromium. This leads to the
On Wed, Oct 7, 2009 at 11:13 AM, Andrew Scherkus scher...@chromium.orgwrote:
It'd be nice to have a non-distracting visual indicator, but to play the
devil's advocate...
What about intentionally CPU intensive sites that use canvas, video,
WebGL?
What about scenarios where it's a plugin
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/13361
http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests%20%28dbg%29%281%29
--= Automatically closing tree for
On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote:
On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote:
Why will it certainly not work? From what (little) I understand,
SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably
one could simulate
On Wed, Oct 7, 2009 at 21:25, Jeremy Orlow jor...@chromium.org wrote:
I could't imagine many users understanding a feature like this much less
finding it particularly useful.
That's right, an average user would be only confused. Just exposing this
info (cpu-hungriness) to extensions seems
My preference would be to place them inside Chromium
Framework.framework, then. If you need to, you can put them inside
Chromium Helper.app/Contents/MacOS instead, but I'm trying really hard
to minimize the amount of stuff inside the app and the helper app.
You can get the framework as a bundle
On Wed, Oct 7, 2009 at 12:25 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Oct 7, 2009 at 11:45 AM, Charles Reis cr...@chromium.org wrote:
On Wed, Oct 7, 2009 at 11:13 AM, Andrew Scherkus
scher...@chromium.orgwrote:
It'd be nice to have a non-distracting visual indicator, but to
(adding people more familiar with the release process...)
On Wed, Oct 7, 2009 at 20:16, Amit Kishnani akish...@adobe.com wrote:
Hey Elliot,
thanks for quick turnaround.
the trunk (svn) : http://src.chromium.org/svn/trunk/src/chrome/VERSION is
MAJOR=4
MINOR=0
BUILD=222
PATCH=1
but I
Pawel, I was responding to the idea of suspending a tab. I agree that
exposing this information to extensions wouldn't be too hard and could be
quite useful.
On Wed, Oct 7, 2009 at 12:37 PM, Charles Reis cr...@chromium.org wrote:
On Wed, Oct 7, 2009 at 12:25 PM, Jeremy Orlow
On Wed, Oct 7, 2009 at 12:35 PM, Charles Reis cr...@google.com wrote:
Only power users, which is why I think such a button only belongs in an
extension. (Sorry if that part wasn't clear.)
Basically, I tend to have lots of tabs open, but I'm only using a small set
at any time. That means I
What is @loader_path relative off of?
On Wed, Oct 7, 2009 at 12:35 PM, Mark Mentovai m...@chromium.org wrote:
My preference would be to place them inside Chromium
Framework.framework, then. If you need to, you can put them inside
Chromium Helper.app/Contents/MacOS instead, but I'm trying
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
sorta relative to the thing loading this
TVL
On Wed, Oct 7, 2009 at 3:52 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote:
What is @loader_path relative off of?
On Wed, Oct 7, 2009 at 12:35 PM,
Albert J. Wong wrote:
What is @loader_path relative off of?
@loader_path is the directory that contains whatever is being loaded.
While loading the main executable, @loader_path is equivalent to
@executable_path.
If your three dylibs refer to one another and are always in the same
directory,
Actually, the original distinction was stuff that could be shared
across computers and stuff that couldn't be shared (i.e., local
state). I think originally this was for the difference between stuff
that a mounted home directory would sync and stuff that wouldn't sync.
In practice, I think it's
On quirksmode, sponsored by Google, apparently:
http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html
--
Erik Corry, Software Engineer
Google Denmark ApS. CVR nr. 28 86 69 84
c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
Copenhagen K, Denmark.
On Wed, Oct 7, 2009 at 12:52 PM, Tony Chang t...@chromium.org wrote:
Actually, the original distinction was stuff that could be shared
across computers and stuff that couldn't be shared (i.e., local
state). I think originally this was for the difference between stuff
that a mounted home
The quasi-defunct profile system that uses the enable-udd-profiles
still has a separate Local State file and safe browsing databases
because it used different user data directory (udd).
This change seems orthogonal to the profile system as it is currently
implemented. We can resplit the
On Wed, Oct 7, 2009 at 1:26 PM, Tony Chang t...@chromium.org wrote:
The quasi-defunct profile system that uses the enable-udd-profiles
still has a separate Local State file and safe browsing databases
because it used different user data directory (udd).
This change seems orthogonal to the
The thing about the media layout tests is ~2 weeks ago all of them were
failing. We've flipped switched to get them running and even after
disabling a bunch due to flakiness we're still ahead -- just need to keep up
the fixes.
Andrew
On Wed, Oct 7, 2009 at 9:36 AM, Peter Kasting
Automatically closing tree for compile on Linux Builder (ChromeOS)
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/4193
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29
--= Automatically closing tree
Umm... shouldn't we be looking into why the tab is taking so much CPU? :)
For example, back in April I saw a similar thing happen on Facebook and with
WinDbg found that WebKit was simply running in an infinite loop. The WebKit
team jumped on this and submitted a fix just 2 days after I reported
I'm trying to run gclient sync, and it seems to get stuck on updating
webkit:
dhcp-172-31-134-235:Chromium nickbaum$ gclient sync
running 'svn update /Users/Shared/Chromium/src-internal' in
'/Users/Shared/Chromium'
At revision 3449.
running 'svn update
Automatically closing tree for unit_tests on Mac10.5 Tests
http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Tests/builds/6250
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Mac10.5%20Tests
--= Automatically closing tree for unit_tests on Mac10.5 Tests =--
If you don't care about gyp or cross-compiling, you can skip this message.
I've been experimenting with adding host support for cross-compiling into
gyp. By this, I mean being able to use the cross-compiler to build Chrome,
but still using the host compiler for build tools. Regular Chrome, with v8
Automatically closing tree for compile on Chromium Builder (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/11678
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29
--= Automatically closing tree for
It seems like another approach would be to use the target types to indicate
if the library or executable is for the host or native (ie-add types for
host vs. target), then you could use target_conditions to have different
flags.
TVL
On Wed, Oct 7, 2009 at 10:06 PM, Antoine Labour
In fixing a Mac bug, I recently added a layer to intercept
-[NSApplication sendAction:to:from:] and make sure a certain message
wasn't forwarded if the target was known to be freed. Since this is
sort of a core function for event dispatch, now we're seeing
crashdumps with my new method on the
55 matches
Mail list logo
