On Wed, Aug 19, 2009 at 10:56 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, Aug 19, 2009 at 9:49 PM, Brett Wilsonbre...@chromium.org wrote:
On Wed, Aug 19, 2009 at 6:00 PM, Dean McNameede...@chromium.org wrote:
I kinda feel like this is one of those things you can try hard to
Tonight, in r23805, I enabled a reflective cross-site scripting (XSS)
filter for Chromium. The goal of this filter is to automatically
protect web sites from certain kinds of XSS vulnerabilities. The
filter might have some false positives (and block legitimate web site
behavior). If you see a
I reverted the change because the page cycler regression appears to be
real. I'm not entirely sure how to track down the issue. Is there a
way I can run page cycler locally? The page_cycle_tests complains
that I don't have the test data...
Adam
On Wed, Aug 19, 2009 at 11:42 PM, Adam
Sadly, the page cycler data is not available publicly.-Darin
On Thu, Aug 20, 2009 at 12:00 AM, Adam Barth aba...@chromium.org wrote:
I reverted the change because the page cycler regression appears to be
real. I'm not entirely sure how to track down the issue. Is there a
way I can run page
Hi,
Is there anyway to 'lock' the Render process in chromium? Which means
Renderer does not do these during the 'lock' period
* repaint the screen
* no dom modification
* no render tree modification
* no javascript context modification
Thank you for any idea.
On Thu, Aug 20, 2009 at 2:00 AM, Dean McNameede...@chromium.org wrote:
I kinda feel like this is one of those things you can try hard to
premeditate, but in the end you'll just have to deal with it being
ugly for a while and hope it eventually converges to something better.
Sort of a
On Thu, Aug 20, 2009 at 6:21 AM, Ben Goodger (Google)b...@chromium.org wrote:
I don't know much about the technical details at play here, but a
couple of high level notes:
- I am sympathetic to concerns around codebase cleanliness. Many
people (like Brett) have spent very many months
On Wed, Aug 19, 2009 at 10:18 PM, Marc-Antoine Ruelmar...@google.com wrote:
I don't mind as long it's documented on dev.chromium.org.
Ben, ping me if you want to setup a freebsd slave on fyi. As long as you
want to babysit it. :)
Cool - I haven't got that far yet, but when it builds, I'll be
Microsoft posted a KB article on this:
http://blogs.msdn.com/windowssdk/archive/2009/08/07/installing-windows-sdk-for-server-2008-v6-1-after-vs2008-sp1-causes-conflicts-with-security-update-kb971092.aspx
HTH
On Wed, Aug 5, 2009 at 8:22 PM, Thiago Farina thiago.far...@gmail.comwrote:
I'm in
On Thu, Aug 20, 2009 at 6:56 AM, Brett Wilsonbre...@chromium.org wrote:
On Wed, Aug 19, 2009 at 9:49 PM, Brett Wilsonbre...@chromium.org wrote:
On Wed, Aug 19, 2009 at 6:00 PM, Dean McNameede...@chromium.org wrote:
I kinda feel like this is one of those things you can try hard to
Statement of problem: When looking to change the settings on the page
you have to refresh the entire screen to get the controls to work
Tested in other browser: I have tested this in both FF3 and 3.5 and
you don't have to do this in those versions.
OS: Ubuntu 9.04 or Eeebuntu 3
Chromium version:
On Thu, Aug 20, 2009 at 6:06 AM, Ben Laurieb...@chromium.org wrote:
I'd be happy to do that. When I do, there's something that's already
puzzling me, and that's OS_POSIX.
I don't have a copy of the POSIX standard, at least not a recent one,
so its hard to know what is or isn't POSIX, and I
kill -STOP pid of renderer
?
On Thu, Aug 20, 2009 at 12:23 AM, n179911n179...@gmail.com wrote:
Hi,
Is there anyway to 'lock' the Render process in chromium? Which means
Renderer does not do these during the 'lock' period
* repaint the screen
* no dom modification
* no render tree
You're probably best off just reporting it as a bug; as long as you've
at least attempted to consult the bug tracker (off the top of my head
that doesn't look like any of the bugs we currently have filed), more
plugin problem scenarios are always helpful.
On Thu, Aug 20, 2009 at 3:29 AM,
Thanks evan, after more digging around I have found a bug that is
exactly the same as I'm seeing on Linux, so I have commented there.
Bug #1645
Nick
On Aug 20, 2:33 pm, Evan Martin e...@chromium.org wrote:
You're probably best off just reporting it as a bug; as long as you've
at least
Thanks Evan.
I dug around a little deeper and someone had reported it back 2008,
and the problem is exactly the same today on the Linux version today.
Here is a link to the bug. http://bit.ly/ZlqQ1
Nick
On Aug 20, 2:33 pm, Evan Martin e...@chromium.org wrote:
You're probably best off just
I'd say don't bother and directly install the Microsoft SDK for Windows 7 at
http://www.microsoft.com/downloads/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505displaylang=en
Updated
http://sites.google.com/a/chromium.org/dev/developers/how-tos/build-instructions-windows
accordingly.
The main issue I had with splitting unit_tests is the porosity between
chrome/browser and chrome/renderer. There's way too much direct calls
between both.
http://code.google.com/p/chromium/issues/detail?id=4301
M-A
On Wed, Aug 19, 2009 at 11:25 PM, Lei Zhang thes...@chromium.org wrote:
+1 for
For what it's worth, Alt-F is already used by extensions like
FlashBlock for Chrome:
http://userscripts.org/scripts/show/46673
On Wed, Aug 19, 2009 at 4:33 PM, Peter Kastingpkast...@google.com wrote:
On Wed, Aug 19, 2009 at 4:31 PM, Mohamed Mansour m...@chromium.org wrote:
Are you guys
We do boot with /3GB on the bots already. I talked with M-A about
/LARGEADDRESSAWARE and apparently in the past we've had issues with it
and the sandbox and v8, so we're not using it anywhere. It's possible
that those issues have been addressed since the last time M-A looked
into this, but
Sometimes all you have to do is send an email saying that you give up
in order to find a solution. ;-)
I did a little more poking around last night and found one test
(SpellCheckTest.SpellCheckText, which only recently landed) that was
contributing 300-400MB of private bytes to the address space
The v8 team did some amazing work this quarter building a working
64-bit port. After a handful of changes on the Chromium side, I've
had Chromium Linux building on 64-bit for the last few weeks. I
believe mmoss or tony is going to get a buildbot running, and working
on packaging.
You can
Awesome! I'll work on the buildbot, then start marking all the
ia32-libs bugs invalid :)
On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote:
The v8 team did some amazing work this quarter building a working
64-bit port. After a handful of changes on the Chromium side, I've
w00t, nice job.
On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote:
The v8 team did some amazing work this quarter building a working
64-bit port. After a handful of changes on the Chromium side, I've
had Chromium Linux building on 64-bit for the last few weeks. I
Awesome! :)
FYI, video will not work out of the box since the ffmpeg binaries we have
are 32-bit. We need a bit of work to shift them over. If you see bugs
there, it's expected.
-Albert
On Thu, Aug 20, 2009 at 10:18 AM, Michael Moss mm...@chromium.org wrote:
Awesome! I'll work on the
How does the v8 perf look like relative to 32-bit?
I guess we ought to set up perf bots for startup/memory/etc. as well;
I'd expect we improve on those metrics on our 64-bit buildbots due to
more sharing with other apps on the system.
On Thu, Aug 20, 2009 at 8:44 AM, Dean
On Thu, Aug 20, 2009 at 10:26 AM, Evan Martine...@chromium.org wrote:
How does the v8 perf look like relative to 32-bit?
I guess we ought to set up perf bots for startup/memory/etc. as well;
I'd expect we improve on those metrics on our 64-bit buildbots due to
more sharing with other apps
Including files like render_messages.h and automation_messages.h from other
header files is unnecessary and slows down the build (adds about ~100K lines
of headers to each cc file). Last time I removed all these occurrences, it
improved the build time by 15%. Looks like a few more crept in now,
On Thu, Aug 20, 2009 at 2:26 PM, Evan Martine...@chromium.org wrote:
On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurieb...@chromium.org wrote:
I'd be happy to do that. When I do, there's something that's already
puzzling me, and that's OS_POSIX.
I don't have a copy of the POSIX standard, at least
Cool! Thanks so much. I'm going to write a presubmit check for that.
On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.org wrote:
Including files like render_messages.h and automation_messages.h from other
header files is unnecessary and slows down the build (adds about ~100K
Great! Please try to add this to an existing check, or do it in a way that
doesn't involve the files being read once for each presubmit check, as the
presubmit step is already too slow.
On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr.
phajdan...@chromium.orgwrote:
Cool! Thanks so much. I'm
I started a page to collect the common terms/lingo that gets used in
chromium development. It's pretty anemic right now, but if a term keeps
needing to get reexplained to people, please add it to the page. Also, if
anyone has a better idea for formatting, please feel free to change it. I
tried
Are you positive it's the per-file presubmit checks slowing things down? If
so, maybe the presubmit stuff needs to be re-factored? Right now, it does
each presubmit check one by one (and each check might read in the files).
If it were changed to go file by file (reading fully into memory,
On Thu, Aug 20, 2009 at 7:32 PM, Evan Martine...@chromium.org wrote:
On Thu, Aug 20, 2009 at 11:15 AM, Ben Laurieb...@chromium.org wrote:
On Thu, Aug 20, 2009 at 2:26 PM, Evan Martine...@chromium.org wrote:
On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurieb...@chromium.org wrote:
I'd be happy to do
On Thu, Aug 20, 2009 at 11:15 AM, Ben Laurieb...@chromium.org wrote:
On Thu, Aug 20, 2009 at 2:26 PM, Evan Martine...@chromium.org wrote:
On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurieb...@chromium.org wrote:
I'd be happy to do that. When I do, there's something that's already
puzzling me, and
Hi Andrew.
This has been fixed.
- Bev
On Wed, Aug 19, 2009 at 2:00 PM, Andrew Scherkus scher...@chromium.orgwrote:
Every so often I like peeking at the test coverage stats, but I'm seeing
403 Forbidden at the moment: http://build.chromium.org/buildbot/coverage/
Andrew
The commit checks is bound to 2x appengine latency (hint hint) since
it parses try job results registered on rietveld and looks up
chromium-status to know if the tree is open.
presubmit_support.py still reads the whole file. It's *supposed* to
only load the new lines from the diff. I just
On Thu, Aug 20, 2009 at 6:31 AM, Evan Martine...@chromium.org wrote:
kill -STOP pid of renderer
?
I don't want the renderer process to die. I just want it 'locked' so
that i can dump out information of the page (DOM, CSS) of the page.
And I want the page unchange during the information
Anybody working on 64-bit breakpad yet?
src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code
has not been ported to your platform yet
I guess worst case, I can turn this off for official 64-bit builds right now.
Michael
On Thu, Aug 20, 2009 at 8:44 AM, Dean
Out of curiosity, what work remains to support a 64bit build on Windows?
On Thu, Aug 20, 2009 at 11:44 AM, Dean McNamee de...@chromium.org wrote:
The v8 team did some amazing work this quarter building a working
64-bit port. After a handful of changes on the Chromium side, I've
had Chromium
On Thu, Aug 20, 2009 at 12:06 PM, Michael Mossmm...@chromium.org wrote:
Anybody working on 64-bit breakpad yet?
src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code
has not been ported to your platform yet
I guess worst case, I can turn this off for official 64-bit builds
On Thu, Aug 20, 2009 at 12:12 PM, Adam Langleya...@chromium.org wrote:
I think 64-bit breakpad is done. Are you sure you're up to date? (and
using the files from breakpad/linux?)
Sorry Dean pointed out that it was minidump-2-core. That should be
removed really. It doesn't work.
AGL
That is just a utility program, no?
On Thu, Aug 20, 2009 at 12:06 PM, Michael Moss mm...@chromium.org wrote:
Anybody working on 64-bit breakpad yet?
src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code
has not been ported to your platform yet
I guess worst case, I can turn
On Thu, Aug 20, 2009 at 1:17 PM, Marshall
Greenblattmagreenbl...@gmail.com wrote:
Out of curiosity, what work remains to support a 64bit build on Windows?
Motivation.
Probably also some sandbox fixes.
A gyp update.
M--A
--~--~-~--~~~---~--~~
Chromium
On Thu, Aug 20, 2009 at 9:38 AM, n179911n179...@gmail.com wrote:
I don't want the renderer process to die. I just want it 'locked' so
that i can dump out information of the page (DOM, CSS) of the page.
And I want the page unchange during the information dumping.
SIGSTOP doesn't kill the
On Thu, Aug 20, 2009 at 11:40 AM, Marc-Antoine Ruel mar...@chromium.orgwrote:
The commit checks is bound to 2x appengine latency (hint hint) since
it parses try job results registered on rietveld and looks up
chromium-status to know if the tree is open.
I wasn't talking about commit check,
On Thu, Aug 20, 2009 at 11:33 AM, Jeremy Orlow jor...@chromium.org wrote:
Are you positive it's the per-file presubmit checks slowing things down?
If so, maybe the presubmit stuff needs to be re-factored? Right now, it
does each presubmit check one by one (and each check might read in the
So, history of this discussion:
http://code.google.com/p/chromium/issues/detail?id=19508
http://code.google.com/p/chromium/issues/detail?id=19648#c15
Basically, I feel that if the attempt is to make Chromium feel like a
native application on all operating systems, the standards of that
operating
On Wed, Aug 19, 2009 at 9:54 PM, Huan Ren hu...@google.com wrote:
On Thu, Aug 6, 2009 at 1:06 PM, John Abd-El-Malek j...@chromium.orgwrote:
This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
You must have your
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote:
1) on a single click to the omnibox, the cursor should be placed. The
contents of the omnibox should not be selected.
We violate this convention on Windows too. We do this because the
most common reason to click in the omnibox
On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote:
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote:
1) on a single click to the omnibox, the cursor should be placed. The
contents of the omnibox should not be selected.
We violate this convention on
Firefox on Linux doesn't. Wasn't one of the main goals to make the
application feel native to the operating system? I could care less
about Windows or OSX focus and selection behavior.
None of the below Linux browsers select the entire URL on the first click:
Firefox
Epiphany
Seamonkey
Galeon
Safari, Camino, and Mac Chromium place the cursor on a single click.
On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote:
On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote:
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote:
1) on a
Oh yikes. Hmm. No, I'm not okay with that.
Three solutions
1) don't select the autocomplete. Do it like Firefox (autocompletions
are in the dropdown, don't mess with what the user is typing)
2) select the autocomplete, but in a way that's clearly different from
normal selection (like, have the
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote:
4) Any time content in the box is selected, it should be in the
PRIMARY buffer.
This would mean that when you type a URL, the autocomplete will
clobber your selection.
Are you ok with that?
The observant will note that these same browsers (on Mac, at least)
allow you to select everything by clicking on the border of the location
bar.
Mike Pinkerton wrote:
Safari, Camino, and Mac Chromium place the cursor on a single click.
On Thu, Aug 20, 2009 at 4:56 PM, Peter
On Thu, Aug 20, 2009 at 2:24 PM, JT Oldsjto...@xnet5.com wrote:
1) don't select the autocomplete. Do it like Firefox (autocompletions
are in the dropdown, don't mess with what the user is typing)
Non-starter.
2) select the autocomplete, but in a way that's clearly different from
normal
On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote:
None of the below Linux browsers select the entire URL on the first click:
Firefox
Epiphany
Seamonkey
Galeon
Midori
Konqueror
Dillo
In fact, I can't find a single browser that does what you claim on Linux.
I am on record
3) make this be the one exception. I still guess I expect ^L to
clobber my selection.
The behavior that Dan implemented is this make an exception one --
with the addition that single-clicking the omnibox also doesn't
clobber.
...whoa, the Firefox behavior is even stranger than I thought.
On Thu, Aug 20, 2009 at 2:30 PM, Viet-Trung Luuviettrung...@gmail.com wrote:
The observant will note that these same browsers (on Mac, at least)
allow you to select everything by clicking on the border of the location
bar.
That's pretty cool! The target area is kind of tiny though...
Adam
On Thu, Aug 20, 2009 at 2:24 PM, JT Olds jto...@xnet5.com wrote:
Oh yikes. Hmm. No, I'm not okay with that.
Three solutions
1) don't select the autocomplete. Do it like Firefox (autocompletions
are in the dropdown, don't mess with what the user is typing)
The entire omnibox hinges on this
On Thu, Aug 20, 2009 at 2:42 PM, Evan Stadeest...@chromium.org wrote:
A lot of webpages highlight stuff without your input (with
javascript). Are you sure you want a webpage to be able to clobber
your clipboard?
In general, this is a bad idea. Imagine a web page selecting this text
cat
On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote:
On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote:
None of the below Linux browsers select the entire URL on the first click:
Firefox
Epiphany
Seamonkey
Galeon
Midori
Konqueror
Dillo
In fact, I
Since everyone has their own opinions on this, isn't it best to just
match platform standards? On Linux, that seems to be triple-click.
On Thu, Aug 20, 2009 at 2:57 PM, James Hawkinsjhawk...@chromium.org wrote:
On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote:
On Thu,
jhawkins++
I am with James on this one. Would save numerous clicks.
-- Mohamed Mansour
On Thu, Aug 20, 2009 at 5:57 PM, James Hawkins jhawk...@chromium.orgwrote:
On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org
wrote:
On Thu, Aug 20, 2009 at 2:02 PM, JT Olds
On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.orgwrote:
Will you accept opinions of the opposite? I love our current behavior
and can't stand having to triple-click in Firefox.
Consider the following cases.
a) The user is trying to completely change the contents of the
One other note: the other Mac browsers in question (Safari, Camino,
etc) provide a page proxy icon which can be clicked to select the
entire contents of the url bar (in case you don't want to use cmd-L).
Mac Chromium is lacking that as we put the favicon in the tab not the
url bar, though we have
On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote:
On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org
wrote:
Will you accept opinions of the opposite? I love our current behavior
and can't stand having to triple-click in Firefox.
Consider the
Awesome, thanks guys.
On Thu, Aug 20, 2009 at 4:20 PM, James Hawkinsjhawk...@chromium.org wrote:
On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote:
On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org
wrote:
Will you accept opinions of the opposite?
Any opposition to globally declaring an operator ostream overload for
TimeDelta in base/time.h?
According to style guide it needs to be fully justified, but it'd be nice to
use DCHECK_xx/EXEPCT_xx/ASSERT_xx with TimeDeltas.
Andrew
--~--~-~--~~~---~--~~
Chromium
I left this comment on http://code.google.com/p/chromium/issues/detail?id=19879
but I'll reiterate here.
FWIW, the results from this statistics gathering really doesn't say
anything about how
many users are surprised or unhappy about how the selection interacts
with the
selection buffer in
Andrew Scherkus wrote:
Any opposition to globally declaring an operator ostream overload for
TimeDelta in base/time.h?
According to style guide it needs to be fully justified, but it'd be nice to
use DCHECK_xx/EXEPCT_xx/ASSERT_xx with TimeDeltas.
I think this is fine.
Mark
On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote:
Any opposition to globally declaring an operator ostream overload for
TimeDelta in base/time.h?
This will pull the stream headers into all files that use time.h. Is that
going to bloat any code or cost compile time?
On Thu, Aug 20, 2009 at 16:02, Peter Kasting pkast...@chromium.org wrote:
On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote:
Any opposition to globally declaring an operator ostream overload for
TimeDelta in base/time.h?
This will pull the stream headers into all
Oops, didn't see how long the thread was :-).
On Thu, Aug 20, 2009 at 7:10 PM, Amanda Walkerama...@chromium.org wrote:
Safari does not. Single click sets the text caret where you click.
On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote:
On Thu, Aug 20, 2009 at 1:36
This thread is massive. Having been the one who wrote the majority of
the Omnibox code on Linux, I can promise you that this debate has
already happened about 15 times previously. I'm not sure there is any
more information here, we've already decided how we want things to
work.
On Thu, Aug 20,
On Thu, Aug 20, 2009 at 9:17 PM, Drew Wilsonatwil...@chromium.org wrote:
I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
although I gather the plan is to eventually upstream it to WebKit, and use
it as our abstraction layer instead of using the (more mutable)
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.org wrote:
I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
although I gather the plan is to eventually upstream it to WebKit, and use
it as our abstraction layer instead of using the (more mutable)
I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
although I gather the plan is to eventually upstream it to WebKit, and use
it as our abstraction layer instead of using the (more mutable) WebCore
APIs? Or is there another motivation?
I'm just curious because it seems
+1 for Peter's suggestion.
TimeDelta has an internal accuracy of microseconds. What resolution/scaling
do you want to print in a check? Sometimes it is minutes, sometimes
seconds, sometimes milliseconds, I doubt that we want microseconds :-/.
Explicit conversion as suggested doesn't seem that
Andrew wants to be able to do:
DCHECK_EQ(expected_time_delta, time_delta);
This can't be done without operator support.
On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote:
+1 for Peter's suggestion.
TimeDelta has an internal accuracy of microseconds. What
I know microseconds aren't a very user-friendly format, but for unit tests
and DCHECKs I'm more interested in whether the assertion is simply true.
Perhaps I'm lazy but I'd prefer:
EXPECT_EQ(kExpected, foo);
error: Value of: foo
Actual: 2100
Expected: kExpected
Which is: 2200
...over:
On Aug 20, 2:56 pm, Peter Kasting pkast...@chromium.org wrote:
On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote:
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote:
1) on a single click to the omnibox, the cursor should be placed. The
contents of the
On Aug 20, 3:18 pm, Evan Martin e...@chromium.org wrote:
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote:
4) Any time content in the box is selected, it should be in the
PRIMARY buffer.
This would mean that when you type a URL, the autocomplete will
clobber your
I would plead strongly with the Mac people to change their decision;
I suspect this would not end well. Mac users in general strongly favor
consistency with the platform over saving a click or two. We've been
trained over the years to single-click to place the cursor, double-
click to highlight
On Aug 20, 2:56 pm, Peter Kasting pkast...@chromium.org wrote:
On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote:
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote:
1) on a single click to the omnibox, the cursor should be placed. The
contents of the
is there a reason this isn't on the wiki?
-- Evan Stade
On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong
(王重傑)ajw...@chromium.org wrote:
I started a page to collect the common terms/lingo that gets used in
chromium development. It's pretty anemic right now, but if a term keeps
needing to
On Aug 20, 3:14 pm, Peter Kasting pkast...@chromium.org wrote:
I chatted with several people just now about the Mac behavior, since unlike
Linux, there aren't blowing away my clipboard concerns and it seemed to me
that the argument above was compelling. According to pinkerton, the
behavior
I think the code path in this case is (as you suggest):
glue code creates vector of WebMessagePortChannels out of an array of
MessagePortChannels.
this gets passed down into WebMessagePortChannel.postMessage()
WebMessagePortChannelImpl.postMessage() sends it to the right thread,
then
+1 Clobbering the primary selection when clicking in the url bar is
@#$ annoying and very un-Linux like.
On Thu, Aug 20, 2009 at 14:02, JT Oldsjto...@xnet5.com wrote:
Firefox on Linux doesn't. Wasn't one of the main goals to make the
application feel native to the operating system? I could
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.org wrote:
I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
although I gather the plan is to eventually upstream it to WebKit, and use
it as our abstraction layer instead of using the (more mutable)
On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.orgwrote:
I have to admit I'm somewhat fuzzy on the motivation behind our webkit
API, although I gather the plan is to eventually upstream it to WebKit, and
I noticed that you haven't done any WebKit merges yet? ;-)
Kidding aside, this effort is about translating webkit/glue into a stable
API that we can live with. We built webkit/glue originally to shield the
majority of the Chromium code base from the constant churn of WebCore. It
helped reduce
Hi,
I have followed the steps here in checking out chromium using git and the
rest of the code using svn:
http://code.google.com/p/chromium/wiki/UsingGit
I am able to build successfully locally on my MacOSX.
From this thread, it looks like I can use git to checkout WebKit source
(instead of
Nope. Feel free to move it, or I'll do it tomorrow.
-A
On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade est...@chromium.org wrote:
is there a reason this isn't on the wiki?
-- Evan Stade
On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong
(王重傑)ajw...@chromium.org wrote:
I started a page to
ported:
http://code.google.com/p/chromium/wiki/Glossary?ts=1250828818updated=Glossary
-- Evan Stade
On Thu, Aug 20, 2009 at 8:57 PM, Albert J. Wong
(王重傑)ajw...@chromium.org wrote:
Nope. Feel free to move it, or I'll do it tomorrow.
-A
On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade
On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.orgwrote:
I have to admit I'm somewhat fuzzy on the motivation behind our webkit
awesome. thanks!
2009/8/20 Evan Stade est...@chromium.org
ported:
http://code.google.com/p/chromium/wiki/Glossary?ts=1250828818updated=Glossary
-- Evan Stade
On Thu, Aug 20, 2009 at 8:57 PM, Albert J. Wong
(王重傑)ajw...@chromium.org wrote:
Nope. Feel free to move it, or I'll do it
On Thu, Aug 20, 2009 at 7:13 PM, Andrew Scherkusscher...@chromium.org wrote:
I know microseconds aren't a very user-friendly format, but for unit tests
and DCHECKs I'm more interested in whether the assertion is simply true.
Perhaps I'm lazy but I'd prefer:
EXPECT_EQ(kExpected, foo);
error:
Looking at the example you gavehow about:
EXPECT_EQ(kExpected.InMilliseconds(), foo.InMilliseconds());
Is that really that painful to write?
...and you could get all the microseconds to compare if you wanted to via
...InMicroseconds().
I suspect you don't really want absolute comparisons at
1 - 100 of 104 matches
Mail list logo
