[chromium-dev] Re: Extensions i18n Design Doc Draft
How about extending this support and also adding an option to use native Chrome strings that are in use in the actual program so extension developers could benefit from your own translations and corrections in the appropriate cases? ☆PhistucK 2009/6/30 Nebojša Ćirić > Hi all, I have initial draft for extensions internationalization effort. > Take a look at > http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/i18n > > Regards, > Nebojsa Ciric > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] A few notes on Reliability FIXIT
We have triaged most of FIXIT bugs. A few quick notes for the week: 1. Fix P1 crash bugs first. FYI, Anthony's script cuts off crashes in following way: - Top 25 P1 - Top 50 P2 (exception to P1 for regressions) - Else P3 2. Consider off loading your FIXIT bugs early. Please take a look at reliability FIXIT bugs assigned to you and punt the ones you don't have time to work on. Please CC huanr or laforge when doing so. 3. There are still Coverity review bugs unassigned. Those are good candidates for people looking for FIXITs to work on. Regards, Huan and Anthony --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] cygwin dependence missing?
I reviewed my layout-tests' output, and found some errors like: 090629 14:28:30 __init__.py:1032 ERROR LayoutTests/http/tests/xmlhttprequest/xml-encoding.html failed: Text diff mismatch Simplified text diff mismatch /cygdrive/e/mychromesrc/src/third_party/cygwin/bin/wdiff: /tmp/t101c.0: No such file or directory I think I missed something about cygwin, right? How to make up? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Extensions i18n Design Doc Draft
Hi all, I have initial draft for extensions internationalization effort. Take a look at http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/i18n Regards, Nebojsa Ciric --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Memory usage in chrome
On 29-Jun-09, at 5:37 PM, Marc-Antoine Ruel wrote: > The measurement timing is important since the OS will trigger page > flush after X number of seconds. If you are not in a hurry, usually > taking measurements 60 seconds after your test is idle will be quite > stable. For what it's worth, our test waited about 3-5 minutes once done to allow the browsers to flush memory. cheers, mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Memory usage in chrome
Actually, I had done testing like that in a VM to get a sense of raw process/threads limits on a low memory system. It's relatively easy to achieve a "fair" level of confidence with a live VM snapshot and making sure to reuse the same timings for measurement. The measurement timing is important since the OS will trigger page flush after X number of seconds. If you are not in a hurry, usually taking measurements 60 seconds after your test is idle will be quite stable. M-A On Sat, Jun 27, 2009 at 7:39 PM, Mike Belshe wrote: > This one is the hardest to test, you need to run a pristinely clean system > to execute. > Also - don't forget to make the browser window sizes the same (and with the > same amount of visible window) for all browsers under test, because if the > kernel can't offload to the graphics card, the display memory will be > counted here. > > But yeah, if you can make all that work, then it is a good test! > mike > > > On Sat, Jun 27, 2009 at 2:50 PM, Linus Upson wrote: > >> If I recall correctly, the best way we found to measure the total memory >> usage of a multi-process system like chrome was to measure the total commit >> charge of windows as you run the test. This will correctly account for >> shared memory, mapped pages that have been touched, kernel memory, etc. I >> don't recall if it includes virtual alloced paged that haven't been made >> real. The big limitation is that your test needs to be the only thing >> running on the machine. >> Linus >> >> >> On Thu, Jun 25, 2009 at 4:11 PM, Mike Beltzner wrote: >> >>> >>> On 25-Jun-09, at 7:02 PM, Mike Belshe wrote: >>> >>> > This screen actually confuses me a little, as the Summary statistics >>> > don't match the summation of the process based statistics. Do you >>> > mean to say your summary statistics take into account the memory >>> > that's being shared across the various processes? >>> > >>> > Correct. >>> > >>> > The "shared" across all processes is a bit of a hack, because you >>> > can't know exactly which pages are shared across every single >>> > process. We do a heuristic. >>> >>> Cool! Good to know. I'll take a peek into that code you mentioned to >>> see what the heuristic is that you're using. >>> >>> > Interestingly, as I watched this value change while webpages were >>> > loading, it tracked the same pattern of growth/decline as "Memory >>> > (Private Working Set)" in the Task Manager, though the values were >>> > usually about 2x or so more. I suppose this is due to the heap >>> > sharing you were speaking of earlier? >>> > >>> > I'm not quite sure what you mean. >>> >>> I'm basically being lazy. I'd like to not have to make my own counter >>> for Private Working Set, so I watched the values of "Memory (Private >>> Working Set)" and "Commit Size" in the Task Manager as the test ran, >>> and noticed that they increased/decreased at the same time, and the >>> delta between them was a near constant 2x. Since my interest here is >>> developing a metric that can help us understand when we're regressing/ >>> improving memory usage, the exact value isn't as important to me as >>> the delta. If the deltas are simply off by a constant factor, I could >>> live with that. >>> >>> As I said: lazy! >>> >>> > >>> > The "Working Set - Private" counter doesn't seem to have a structure >>> > according to the MSDN document; that's what maps to the "Memory >>> > (Private Working Set)" column in the TaskManager. >>> > >>> > Right, I think you have to use QueryWorkingSet, walk the pages and >>> > categorize them yourself. >>> > >>> > OK, I can look into trying that. Though I'm wondering if it's worth >>> > the bother, as the meta-pattern, to me, is more interesting than the >>> > precise megabyte count. >>> > >>> > For a single process browser, it's not worth the effort; I think >>> > it's the only way to know how to account for shared memory. >>> >>> >>> > The closest thing I can find is the "Working Set" counter, which >>> > uses the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and >>> > shows up in the Vista Task Manager as "Working Set (Memory)" >>> > >>> > For multi-proc browsers like chrome, this will way overstate RAM; >>> > there is a good 5-6MB of shared working set in each process. So for >>> > 10 tabs, you'd could an extra 50MB for Chrome if you do it this way. >>> > >>> > Looking both in Task Manager and about:memory, when I have 30 tabs >>> > open I'm not seeing 30 processes. Are you sure you're right about >>> > this point? >>> > >>> > You don't always get a new process for every tab. If two tabs are >>> > connected via javascript, then they'll be in the same process (the >>> > about:memory shows which tabs are in the same process). So, >>> > clicking a link, for example, will open in the same tab, but typing >>> > the URL in the omnibox will create a new process. Others could tell >>> > you more about the exact policy for when you get a new process and >>> > when you don't. >>> >>> Someone just did in IRC, actua
[chromium-dev] RenderViewTest with subframe content
I'm trying to create a unit test to verify change I'm doing to print out
frames.I haven't been able to figure out how to load content into a
subframe. I've tried to create an iframe with src property and catch the
RequestResource message and also tried to write into the frame using
something like this:
Lorem Ipsum:
document.write(frames['sub1'].name);
frames['sub1'].document.write('Cras tempus ante eu felis semper
luctus!
');
This works fine when I run this in Chrome (FF & IE) but when run in the unit
test the rendered document contains an empty subframe and the frame name it
claims to be "undefined". Why is that?
I've tried tracing the IPC between RenderView and RenderViewHost and there
are no messages there I think I should intercept but there
is definitely something I'm missing here so any pointers would be
appreciated.
My current code is here: http://codereview.chromium.org/150046.
Sverrir
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: MYTH: WebKit uses design docs
Or expect responses re: your design doc. ;) Agreed. I see no harm in publishing them. On Mon, Jun 29, 2009 at 12:16 PM, Dimitri Glazkov wrote: > I don't see anything wrong with publishing design docs on webkit-dev. > Just don't proselytize :) > > :DG< > > On Mon, Jun 29, 2009 at 11:40 AM, Jeremy Orlow wrote: >> On Mon, Jun 29, 2009 at 11:07 AM, David Levin wrote: >>> >>> It seems like if you are doing a significant change to an existing area or >>> adding a feature, it is good to explain the change that you're planning to >>> do (and hopefully get input from whoever had been working on that area >>> recently the most). This explanation doesn't have to be >>> a "design doc" though. >>> For example from bug https://bugs.webkit.org/show_bug.cgi?id=25463, >>> >>> "The comments in the bug seem to show a lack of consensus as to whether we >>> want >>> this feature and whether the API is appropriate. These design issues >>> should be >>> hashed out (perhaps on the mailing list) before submitting a patch for >>> code review." >> >> True. >> >> I guess WebKit guys have historically been pretty sensitive to us pushing >> our ways upon them. Maybe we can continue circulating design docs for work >> in WebKit on this mailing list, but keep them on the down low on the WebKit >> mailing list? Maybe post links in bugs, but only bring them up on the >> mailing list when there's specific issues to discuss? >> >> J >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: MYTH: WebKit uses design docs
I don't see anything wrong with publishing design docs on webkit-dev. Just don't proselytize :) :DG< On Mon, Jun 29, 2009 at 11:40 AM, Jeremy Orlow wrote: > On Mon, Jun 29, 2009 at 11:07 AM, David Levin wrote: >> >> It seems like if you are doing a significant change to an existing area or >> adding a feature, it is good to explain the change that you're planning to >> do (and hopefully get input from whoever had been working on that area >> recently the most). This explanation doesn't have to be >> a "design doc" though. >> For example from bug https://bugs.webkit.org/show_bug.cgi?id=25463, >> >> "The comments in the bug seem to show a lack of consensus as to whether we >> want >> this feature and whether the API is appropriate. These design issues >> should be >> hashed out (perhaps on the mailing list) before submitting a patch for >> code review." > > True. > > I guess WebKit guys have historically been pretty sensitive to us pushing > our ways upon them. Maybe we can continue circulating design docs for work > in WebKit on this mailing list, but keep them on the down low on the WebKit > mailing list? Maybe post links in bugs, but only bring them up on the > mailing list when there's specific issues to discuss? > > J > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] A small improvement to make the Mac build more dogfoodable
Hi mac team, I'm using the Chrome Alpha as my main browser on my Mac. Yay! Given that crashes are still fairly frequent, I would suggest implementing "Restore the pages that were open last" sooner rather than later. Right now, for those of us who keep a lot of tabs open, crashes lose a lot of state. With this feature, crashes would be much less of a big deal... and so I'd use it even more. Cheers, -Nick --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: MYTH: WebKit uses design docs
On Mon, Jun 29, 2009 at 11:07 AM, David Levin wrote: > It seems like if you are doing a significant change to an existing area or > adding a feature, it is good to explain the change that you're planning to > do (and hopefully get input from whoever had been working on that area > recently the most). This explanation doesn't have to be > a "design doc" though. > > For example from bug https://bugs.webkit.org/show_bug.cgi?id=25463, > > "The comments in the bug seem to show a lack of consensus as to whether we > want > this feature and whether the API is appropriate. *These design issues > should be** > **hashed out (perhaps on the mailing list) before submitting a patch for > code review.*" > > True. I guess WebKit guys have historically been pretty sensitive to us pushing our ways upon them. Maybe we can continue circulating design docs for work in WebKit on this mailing list, but keep them on the down low on the WebKit mailing list? Maybe post links in bugs, but only bring them up on the mailing list when there's specific issues to discuss? J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: [webkit-dev] MSVS vcproj
Might be best if someone with a lot of GYP experience responded to this. Someone brought up using GYP on the WebKit mailing list. -- Forwarded message -- From: Adam Roben Date: Mon, Jun 29, 2009 at 7:02 AM Subject: Re: [webkit-dev] MSVS vcproj To: Seo K Cc: webkit-...@lists.webkit.org On Jun 29, 2009, at 4:57 AM, Seo K wrote: I see many build fixes related to MSVS project files in svn repository > history. I think it is a very error-prone process to maintain MSVC project > files manually because MSVS project files are auto-generated and are not > meant to be edited by hands. Don't you have any plan to change it to use a > script to generate MSVC project files as GYP in Chrome does? > We don't have any plans to switch to using GYP (or a comparable system) on Windows currently. It's true that some parts of the .vcproj files are hard to edit by hand (e.g., the pre- and post-build event commands). But it's actually easier to add/remove source files from them than it is to do the same to an Xcode project. I guess your argument applies to Xcode project files, too. If you think something like GYP would be a good solution for WebKit, it would be helpful for you to provide an overview of how the system works and how using it would make things easier for WebKit developers. -Adam ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Should GYP files be UTF8 Encoded?
Agreed. I've filled an issue on gyp.-BradN On Mon, Jun 29, 2009 at 10:40 AM, Albert J. Wong (王重傑) wrote: > If it's assumed ASCII, would it be sensible to assert it in the gyp parser? > > > On Sat, Jun 27, 2009 at 1:17 PM, Daniel Cowx wrote: > >> >> No use case. I was just creating a new GYP file and wanted to know >> what encoding to save the file as...that's all :-) >> >> On Jun 26, 10:52 pm, Bradley Nelson wrote: >> > The intention was ascii AFAIK. Unless someone has a use case? >> > -BradN >> > >> > >> > >> > On Fri, Jun 26, 2009 at 3:05 PM, Daniel Cowx >> wrote: >> > >> > > Not that I'm aware of. Just wanted to confirm that intention is ASCII >> > > for now unless need arises. >> > >> > > On Jun 26, 2:18 pm, Dan Kegel wrote: >> > > > On Fri, Jun 26, 2009 at 1:50 PM, Daniel Cowx >> > > wrote: >> > > > > Should GYP files be UTF8 Encoded? >> > >> > > > We can probably get away with ascii for now... are there any >> > > > filenames that really need to be in a wider character set? >> >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: MYTH: WebKit uses design docs
Sure we shouldn't expect design docs from people (or request them), but I don't think we should discourage them. I've taken a look at all the WebKit design docs that have floated around (though I suppose most responses have been on this mailing list). I think it's especially important for engineers who are new to WebKit. Personally, the process of writing the design doc really helped me flesh out my ideas before I started writing code. J On Mon, Jun 29, 2009 at 10:22 AM, Eric Seidel wrote: > > It seems to be a common misconception of Google engineers joining > WebKit that WebKit expects design docs like Google does. > > I see Google writing design docs a lot. I saw one or two in my 3 > years at Apple. I've never seen WebKit use them. > > Google engineers posted 3 design docs to webkit-dev last week. I > doubt any of those docs will get much feedback, but I could be wrong. > > > And then this response today: > > On 2009-06-29, at 02:05, Johnny Ding wrote: > > > It will be better to send out detail explanation/design doc before > sending patches if the changes are big:) > > Since when has writing a design document been part of the process of > contributing to WebKit? > > - Mark [Rowe] > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: MYTH: WebKit uses design docs
It seems like if you are doing a significant change to an existing area or adding a feature, it is good to explain the change that you're planning to do (and hopefully get input from whoever had been working on that area recently the most). This explanation doesn't have to be a "design doc" though. For example from bug https://bugs.webkit.org/show_bug.cgi?id=25463, "The comments in the bug seem to show a lack of consensus as to whether we want this feature and whether the API is appropriate. *These design issues should be** **hashed out (perhaps on the mailing list) before submitting a patch for code review.*" Dave On Mon, Jun 29, 2009 at 10:22 AM, Eric Seidel wrote: > > It seems to be a common misconception of Google engineers joining > WebKit that WebKit expects design docs like Google does. > > I see Google writing design docs a lot. I saw one or two in my 3 > years at Apple. I've never seen WebKit use them. > > Google engineers posted 3 design docs to webkit-dev last week. I > doubt any of those docs will get much feedback, but I could be wrong. > > > And then this response today: > > On 2009-06-29, at 02:05, Johnny Ding wrote: > > > It will be better to send out detail explanation/design doc before > sending patches if the changes are big:) > > Since when has writing a design document been part of the process of > contributing to WebKit? > > - Mark [Rowe] > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Should GYP files be UTF8 Encoded?
If it's assumed ASCII, would it be sensible to assert it in the gyp parser? On Sat, Jun 27, 2009 at 1:17 PM, Daniel Cowx wrote: > > No use case. I was just creating a new GYP file and wanted to know > what encoding to save the file as...that's all :-) > > On Jun 26, 10:52 pm, Bradley Nelson wrote: > > The intention was ascii AFAIK. Unless someone has a use case? > > -BradN > > > > > > > > On Fri, Jun 26, 2009 at 3:05 PM, Daniel Cowx > wrote: > > > > > Not that I'm aware of. Just wanted to confirm that intention is ASCII > > > for now unless need arises. > > > > > On Jun 26, 2:18 pm, Dan Kegel wrote: > > > > On Fri, Jun 26, 2009 at 1:50 PM, Daniel Cowx > > > wrote: > > > > > Should GYP files be UTF8 Encoded? > > > > > > We can probably get away with ascii for now... are there any > > > > filenames that really need to be in a wider character set? > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] MYTH: WebKit uses design docs
It seems to be a common misconception of Google engineers joining WebKit that WebKit expects design docs like Google does. I see Google writing design docs a lot. I saw one or two in my 3 years at Apple. I've never seen WebKit use them. Google engineers posted 3 design docs to webkit-dev last week. I doubt any of those docs will get much feedback, but I could be wrong. And then this response today: On 2009-06-29, at 02:05, Johnny Ding wrote: > It will be better to send out detail explanation/design doc before sending > patches if the changes are big:) Since when has writing a design document been part of the process of contributing to WebKit? - Mark [Rowe] --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 3.0.190.4 Dev Release Release Notes
3.0.190 is the current developer channel build. Its release notes are at http://dev.chromium.org/getting-involved/dev-channel/release-notes as usual. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] 3.0.190.4 Dev Release Release Notes
Any plans of adding the notes for the patch?I know people will be asking questions (they always do). Thank you! ☆PhistucK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: middle click on home
Yes, it can also close tabs. I meant to emphasis the _background_ part of the operation. It also opens _in_the_background_. When it closes a tab, it closes it in the background too ;) - Itai On Jun 29, 10:01 am, Mike Pinkerton wrote: > > Middle-click always opens a new tab in the background and making > > exceptions is just likely to confuse users. > > Except when middle-clicking on a tab means "close the tab". So it > means both open and close, depending on the context. > > -- > Mike Pinkerton > Mac Weenie > pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How does chromium use SkCanvas
Thank you very much for the detailed response. On Mon, Jun 29, 2009 at 4:49 AM, Amanda Walker wrote: > Sorry for the typos--I'm still working on my first coffee of the day :-). > > On Mon, Jun 29, 2009 at 7:47 AM, Amanda Walker wrote: >> There are no active plans at the moment, but it could be done if a >> strong reason to arose. > > to -> to do so > >> code charing with Apple. > > charing -> sharing > > --Amanda > (off to finish that coffee) > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: middle click on home
> Middle-click always opens a new tab in the background and making > exceptions is just likely to confuse users. Except when middle-clicking on a tab means "close the tab". So it means both open and close, depending on the context. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: middle click on home
@krtumay: I think you are confused now. Evan was asking about the Home button (which optionally appears in the navigation bar, next to reload). NTP can also be opened in the foreground as a new tab using the small '+" icon. The '+' actually does not support middle-click, you must use left-click. Middle-click always opens a new tab in the background and making exceptions is just likely to confuse users. We are trying to keep things as predictable as possible which is important for software that does not come with a manual. - Itai On Jun 29, 3:19 am, krtulmay wrote: > Consistency with other tabs opening in the background is fine, but I > must agree with Evan on suggesting that the New Tab page should > clearly be an exception. Since you can always open an NTP and there > are so many ways to do it, you would never want to queue any NTPs in > the background, and the only time you ever need an NTP is if you need > it *right now*, so it should open in the foreground. This is a > clearly needed exception. > > And actually, my question about tabs opening in the background should > be generalized to Chrome's default of opening tabs in the background. > It is not fine for the 50% of users who do want tabs to open in the > foreground. And if Google has testing that says the otherwise, I > would like to see an explicit statement saying so and preferably with > quantified stats please. > > On Jun 27, 5:59 pm, Peter Kasting wrote: > > > > > I argued from the point of consistency and mentioned my personal preference > > only as an afternote to point out that the consistent behavior would not be > > universally despised. > > > PK > > > On Jun 27, 2009 4:08 PM, "krtulmay" wrote: > > > This is fine except for the other 50% of users who do want the browser > > to change tabs for them. > > > And before you reply with "there are more than 50% of users who want > > new tabs queued in the background" or say that it's your preference, I > > would like to see explicitly a statement from Google's testing if it > > actually is so and preferably with quantified stats please. > > > On Jun 26, 5:22 pm, Peter Kasting wrote: > Given that > > there are a large numbe... > > > > On Jun 26, 2009 5:09 PM, "Evan Martin" wrote: > > > > On Fri, Jun 26, 2009 at 5:06 PM, Peter Kasting > > > wrote: > > > I don't underst... > > > --~--~-~--~~~---~--~~ Chromium Developers > > mailing list: 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-dev] Re: tests_expectations.txt
2009/6/29 David Jones : > But in my chromium source, I didn't find a tests_fixable.txt or > tests_ignored.txt, but a test_expectations.txt. > Is that a carelessness while writing "WebKit Layout Tests"?? No, it's a carelessness about updating it :-). Originally, there were two files that specified "ignored" and "not passing but fixable". Some time ago, these were merged into a single file to make maintaining it easier. It looks like that document was never updated to match. I have just updated it. Thanks, Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How does chromium use SkCanvas
Sorry for the typos--I'm still working on my first coffee of the day :-). On Mon, Jun 29, 2009 at 7:47 AM, Amanda Walker wrote: > There are no active plans at the moment, but it could be done if a > strong reason to arose. to -> to do so > code charing with Apple. charing -> sharing --Amanda (off to finish that coffee) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How does chromium use SkCanvas
2009/6/29 PhistucK : > Are there any plans of moving to Skia on Mac? There are no active plans at the moment, but it could be done if a strong reason to arose. > Why is it not used, anyway? There are a few reasons, mostly centered around rendering fidelity: - For text, we wanted to use CoreGraphics/ATSUI/etc. in order to render text that looks right to Mac users (especially antialiasing and hinting), and handles laying out Unicode text properly. Windows has the same concern, which is why it uses GDI and calls system DLLs to draw text instead of using Skia. Note that Apple provided the latter as an option after Safari for Windows was released--users are very picky about text rendering details. - We knew that plugins would require maintaining a CoreGraphics drawing context. - The already working, debugged code for rendering with CoreGraphics was the most complete drawing code in WebKit. This was not true for Windows (remember that Apple's windows port of WebKit actually uses a private port of CoreGraphics, which is not redistributable). This presented the following major alternatives: (a) Use Skia the way the Windows version does, and jump out to CoreGraphics just for text. (b) Use Skia for everything, and use FreeType for text rasterization plus Pango for unicode layout. (c) Use the existing CoreGraphics drawing code, and refactor USE(CG) vs PLATFORM(MAC) where necessary. We had (and probably still have) some advocates for (a)--it would increase code sharing between the Mac and Windows versions of Chromium. (b) is basically the approach that the Linux version uses. (c) provided the highest degree of fidelity with Safari and with platform rendering expectations, and provides the greatest amount of code charing with Apple. It also seemed the least complex at the time we had to chose (since we didn't have the linux version as a reference point for how much effort would be involved in (b), it was really a choice between (a) and (c)). We actually tried (a) initially, but it turned out to be quite a bit more complex than it appeared, so we fell back to (c). In the mean time, a bunch of that code has been reworked and cleaned up (mostly by Brett Wilson), so revisiting the use of Skia for more (or all) rendering on the Mac might be less complex now than it was initially. Does that help? --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: middle click on home
Consistency with other tabs opening in the background is fine, but I must agree with Evan on suggesting that the New Tab page should clearly be an exception. Since you can always open an NTP and there are so many ways to do it, you would never want to queue any NTPs in the background, and the only time you ever need an NTP is if you need it *right now*, so it should open in the foreground. This is a clearly needed exception. And actually, my question about tabs opening in the background should be generalized to Chrome's default of opening tabs in the background. It is not fine for the 50% of users who do want tabs to open in the foreground. And if Google has testing that says the otherwise, I would like to see an explicit statement saying so and preferably with quantified stats please. On Jun 27, 5:59 pm, Peter Kasting wrote: > I argued from the point of consistency and mentioned my personal preference > only as an afternote to point out that the consistent behavior would not be > universally despised. > > PK > > On Jun 27, 2009 4:08 PM, "krtulmay" wrote: > > This is fine except for the other 50% of users who do want the browser > to change tabs for them. > > And before you reply with "there are more than 50% of users who want > new tabs queued in the background" or say that it's your preference, I > would like to see explicitly a statement from Google's testing if it > actually is so and preferably with quantified stats please. > > On Jun 26, 5:22 pm, Peter Kasting wrote: > Given that > there are a large numbe... > > > On Jun 26, 2009 5:09 PM, "Evan Martin" wrote: > > > On Fri, Jun 26, 2009 at 5:06 PM, Peter Kasting > > wrote: > > > I don't underst... > > --~--~-~--~~~---~--~~ Chromium Developers > mailing list: chromium-dev... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
