Re: [chromium-dev] layout-test outputs and spell-checker
Hi Jeremy, et al, Sorry for my super-slow update. To investigate this issue deeply, this problem may be caused by font-smoothing since I can get the correct output when I execute 'defaults -currentHost write -g AppleFontSmoothing -int 0' on my mac book and disable font-smoothing. (I usually set this value to 2 medium - best for plat panel.) If I recall correctly, test_shell used to call SetDefaultsToLayoutTestValues() via DefTestShellPlatformDelegate::SelectUnifiedTheme() to disable the font-smoothing while layout tests as WebKit DumpRenderTree does. Nevertheless, the current test_shell doesn't seems to call the function any longer. So, I'm wondering whether or not this is an intentional change. (It may be a good idea to keep disabling such tests and send the review request for this change.) Best regards, Hironori Bono E-mail: hb...@chromium.org 2009/12/17 Hironori Bono (坊野 博典) hb...@chromium.org: Hi Jeremy, Thank you for your quick response. To check the source of the expected image, I notice it comes from the WebKit tree (i.e. third_party/WebKit/LayoutTests/platform/mac/editing/selection/unrendered-002-expected.png). So, I would like to run WebKit layout tests, see its output images, and investigate the font used by WebKit layout test. By the way, I'm using Leopard (10.5.8 Build 9L31a) but its locale is Japanese. :) Regards, Hironori Bono E-mail: hb...@chromium.org 2009/12/16 Jeremy Moskovich jer...@chromium.org: Hi Horonori, Thanks for taking a look at this!! What kinds of differences are you seeing without the new spellchecker class? The only notable difference seems to be that the fonts are slightly different vs. the expected output. Where is the expected output coming from? What OS version are you running this on? btw. The scrollbar diffs are to expected as we draw scrollbars differently in Chrome than Safari does. Best regards, Jeremy 2009/12/16 Hironori Bono (坊野 博典) hb...@chromium.org Greetings chromium-developers, Sorry for my beginner's question in advance. To fix a long-lasting issues: Issue 11577 (*1) and Issue 23497 (*2), I have implemented a MockSpellcheck class (*3), which is a mock implementation of our spell-checker used for layout tests. Even though this change can fix most layout-test failures listed in Issue 23497, there are a layout test that fails on an unknown reason, editing/selection/unrendered-002.html. To run such tests on my Mac, our test_shell outputs very similar images as the expected one but actually different ones as shown in the attached pictures. Would it be possible to give me your thoughts about why our test_shell cannot create the expected image for this case? (*1) http://crbug.com/11577 (*2) http://crbug.com/23497 (*3) http://codereview.chromium.org/493003/show Best regards, Hironori Bono E-mail: hb...@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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] layout-test outputs and spell-checker
Greetings chromium-developers, Sorry for my beginner's question in advance. To fix a long-lasting issues: Issue 11577 (*1) and Issue 23497 (*2), I have implemented a MockSpellcheck class (*3), which is a mock implementation of our spell-checker used for layout tests. Even though this change can fix most layout-test failures listed in Issue 23497, there are a layout test that fails on an unknown reason, editing/selection/unrendered-002.html. To run such tests on my Mac, our test_shell outputs very similar images as the expected one but actually different ones as shown in the attached pictures. Would it be possible to give me your thoughts about why our test_shell cannot create the expected image for this case? (*1) http://crbug.com/11577 (*2) http://crbug.com/23497 (*3) http://codereview.chromium.org/493003/show Best regards, Hironori Bono E-mail: hb...@chromium.org -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-devattachment: unrendered-002-expected.pngattachment: unrendered-002-actual.pngattachment: unrendered-002-diff.png
Re: [chromium-dev] layout-test outputs and spell-checker
Hi Jeremy, Thank you for your quick response. To check the source of the expected image, I notice it comes from the WebKit tree (i.e. third_party/WebKit/LayoutTests/platform/mac/editing/selection/unrendered-002-expected.png). So, I would like to run WebKit layout tests, see its output images, and investigate the font used by WebKit layout test. By the way, I'm using Leopard (10.5.8 Build 9L31a) but its locale is Japanese. :) Regards, Hironori Bono E-mail: hb...@chromium.org 2009/12/16 Jeremy Moskovich jer...@chromium.org: Hi Horonori, Thanks for taking a look at this!! What kinds of differences are you seeing without the new spellchecker class? The only notable difference seems to be that the fonts are slightly different vs. the expected output. Where is the expected output coming from? What OS version are you running this on? btw. The scrollbar diffs are to expected as we draw scrollbars differently in Chrome than Safari does. Best regards, Jeremy 2009/12/16 Hironori Bono (坊野 博典) hb...@chromium.org Greetings chromium-developers, Sorry for my beginner's question in advance. To fix a long-lasting issues: Issue 11577 (*1) and Issue 23497 (*2), I have implemented a MockSpellcheck class (*3), which is a mock implementation of our spell-checker used for layout tests. Even though this change can fix most layout-test failures listed in Issue 23497, there are a layout test that fails on an unknown reason, editing/selection/unrendered-002.html. To run such tests on my Mac, our test_shell outputs very similar images as the expected one but actually different ones as shown in the attached pictures. Would it be possible to give me your thoughts about why our test_shell cannot create the expected image for this case? (*1) http://crbug.com/11577 (*2) http://crbug.com/23497 (*3) http://codereview.chromium.org/493003/show Best regards, Hironori Bono E-mail: hb...@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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Linux build bots
Greetings chromium-developers, sheriffs, and troopers, As you can see in our buildbot waterfall page, three build bots has been stopping for a long time, Chromium Linux, Chromium Linux x64, Modules Linux since I noticed they seemed to be sick and stopped building them. Unfortunately, I wasn't able to fix them even though I tried re-building them. I'm deeply sorry for all chromium developers, especially sheriffs who keep the Chromium builds green. (*1) http://build.chromium.org/buildbot/waterfall/waterfall Regards, Hironori Bono E-mail: hb...@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] build errors while compiling tcmalloc with gcc 4.4
Greetings chromium developers,
Today, I encountered some the following build errors while compiling
tcmalloc with gcc 4.4.
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Compiling
/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc/src/symbolize.o
Compiling
/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc_linux.o
Compiling
/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc_unittests/unittest_utils.o
In file included from tcmalloc/src/symbolize.cc:37:
tcmalloc/src/symbolize.h:45: error: 'uintptr_t' was not declared in this scope
tcmalloc/src/symbolize.h:45: error: template argument 1 is invalid
tcmalloc/src/symbolize.h:45: error: template argument 3 is invalid
tcmalloc/src/symbolize.h:45: error: template argument 4 is invalid
tcmalloc/src/symbolize.h:45: error: invalid type in declaration
before ';' token
unittest_utils.cc:10: error: 'size_t' has not been declared
unittest_utils.cc: In function 'int snprintf(char*, int, const char*, ...)':
unittest_utils.cc:12: error: 'va_list' was not declared in this scope
unittest_utils.cc:12: error: expected ';' before 'args'
unittest_utils.cc:13: error: 'args' was not declared in this scope
unittest_utils.cc:13: error: 'va_start' was not declared in this scope
unittest_utils.cc:14: error: '_vsnprintf' was not declared in this scope
unittest_utils.cc:15: error: 'va_end' was not declared in this scope
scons: ***
[/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc_unittests/unittest_utils.o]
Error 1
tcmalloc/src/symbolize.cc: In function 'bool Symbolize(char*, int,
SymbolMap*)':
tcmalloc/src/symbolize.cc:134: error: expected initializer before 'iter'
tcmalloc/src/symbolize.cc:135: error: 'iter' was not declared in this scope
tcmalloc/src/symbolize.cc:135: error: request for member 'end' in '*
symbolization_table', which is of non-class type 'int'
tcmalloc/src/symbolize.cc:168: error: expected initializer before 'fill'
tcmalloc/src/symbolize.cc:172: error: 'fill' was not declared in this scope
tcmalloc/src/symbolize.cc:140: warning: ignoring return value of
'ssize_t write(int, const void*, size_t)', declared with attribute
warn_unused_result
scons: ***
[/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc/src/symbolize.o]
Error 1
tcmalloc_linux.cc: In function 'void PrintStats(int)':
tcmalloc_linux.cc:491: warning: ignoring return value of 'ssize_t
write(int, const void*, size_t)', declared with attribute
warn_unused_result
tcmalloc_linux.cc: In function 'void ReportLargeAlloc(Length, void*)':
tcmalloc_linux.cc:779: warning: ignoring return value of 'ssize_t
write(int, const void*, size_t)', declared with attribute
warn_unused_result
scons: building terminated because of errors.
It seems tcmalloc code forgot including inttypes.h before using
uintptr_t and forgot checking the return values of write(), which is a
function with a warn_unused_result attribute.
Even though the attached patch tcmalloc_gcc44.txt can fix these
build errors, I would like to ask experts here since this is a
third_party library and I cannot change it. (I don't have any good
idea to fix unittest_utils.cc since vsnprintf() needs a define
_BSD_SOURCE (or _ISOC99_SOURCE) on Linux.)
Regards,
Hironori Bono
E-mail: hb...@chromium.org
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-devIndex: tcmalloc_linux.cc
===
--- tcmalloc_linux.cc (revision 33040)
+++ tcmalloc_linux.cc (working copy)
@@ -488,7 +488,7 @@
char* buffer = new char[kBufferSize];
TCMalloc_Printer printer(buffer, kBufferSize);
DumpStats(printer, level);
- write(STDERR_FILENO, buffer, strlen(buffer));
+ ssize_t size = write(STDERR_FILENO, buffer, strlen(buffer));
delete[] buffer;
}
@@ -776,7 +776,7 @@
printer.printf( %p, stack.stack[i]);
}
printer.printf(\n);
- write(STDERR_FILENO, buffer, strlen(buffer));
+ ssize_t size = write(STDERR_FILENO, buffer, strlen(buffer));
}
namespace {
Index: tcmalloc/src/symbolize.h
===
--- tcmalloc/src/symbolize.h(revision 77)
+++ tcmalloc/src/symbolize.h(working copy)
@@ -33,6 +33,10 @@
#ifndef TCMALLOC_SYMBOLIZE_H_
#define TCMALLOC_SYMBOLIZE_H_
+#ifdef HAVE_INTTYPES_H
+#include inttypes.h
+#endif
+
#include map
using std::map;
Index: tcmalloc/src/symbolize.cc
===
--- tcmalloc/src/symbolize.cc (revision 77)
+++ tcmalloc/src/symbolize.cc (working copy)
@@ -137,7 +137,7 @@
0x% PRIxPTR \n, iter-first);
// TODO(glider): the number of write()s can be reduced by using
// snprintf() here.
-
[chromium-dev] Re: build errors while compiling tcmalloc with gcc 4.4
Greetings, Thank you so much for fixing this. :) I verified I could compile r33049 with gcc 4.4 (Ubuntu 9.10) without any errors. Best regards, Hironori Bono E-mail: hb...@chromium.org On Wed, Nov 25, 2009 at 2:00 PM, William Chan (陈智昌) willc...@google.com wrote: This is fixed now in ToT. I note that the latest version of google-perftools fixes this issue, but we're blocked on some other cross platform issue in google-perftools before we can upgrade. I'll go bug csilvers about it again so we can unfork this soon. 2009/11/24 William Chan (陈智昌) willc...@google.com: 2009/11/24 Hironori Bono (坊野 博典) hb...@chromium.org: Greetings chromium developers, Today, I encountered some the following build errors while compiling tcmalloc with gcc 4.4. scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... Compiling /home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc/src/symbolize.o Compiling /home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc_linux.o Compiling /home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc_unittests/unittest_utils.o In file included from tcmalloc/src/symbolize.cc:37: tcmalloc/src/symbolize.h:45: error: 'uintptr_t' was not declared in this scope tcmalloc/src/symbolize.h:45: error: template argument 1 is invalid tcmalloc/src/symbolize.h:45: error: template argument 3 is invalid tcmalloc/src/symbolize.h:45: error: template argument 4 is invalid tcmalloc/src/symbolize.h:45: error: invalid type in declaration before ';' token unittest_utils.cc:10: error: 'size_t' has not been declared unittest_utils.cc: In function 'int snprintf(char*, int, const char*, ...)': unittest_utils.cc:12: error: 'va_list' was not declared in this scope unittest_utils.cc:12: error: expected ';' before 'args' unittest_utils.cc:13: error: 'args' was not declared in this scope unittest_utils.cc:13: error: 'va_start' was not declared in this scope unittest_utils.cc:14: error: '_vsnprintf' was not declared in this scope unittest_utils.cc:15: error: 'va_end' was not declared in this scope scons: *** [/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc_unittests/unittest_utils.o] Error 1 tcmalloc/src/symbolize.cc: In function 'bool Symbolize(char*, int, SymbolMap*)': tcmalloc/src/symbolize.cc:134: error: expected initializer before 'iter' tcmalloc/src/symbolize.cc:135: error: 'iter' was not declared in this scope tcmalloc/src/symbolize.cc:135: error: request for member 'end' in '* symbolization_table', which is of non-class type 'int' tcmalloc/src/symbolize.cc:168: error: expected initializer before 'fill' tcmalloc/src/symbolize.cc:172: error: 'fill' was not declared in this scope tcmalloc/src/symbolize.cc:140: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result scons: *** [/home/hbono/Chrome/src/sconsbuild/Release/obj/tcmalloc/tcmalloc/tcmalloc/src/symbolize.o] Error 1 tcmalloc_linux.cc: In function 'void PrintStats(int)': tcmalloc_linux.cc:491: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result tcmalloc_linux.cc: In function 'void ReportLargeAlloc(Length, void*)': tcmalloc_linux.cc:779: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result scons: building terminated because of errors. It seems tcmalloc code forgot including inttypes.h before using uintptr_t and forgot checking the return values of write(), which is a function with a warn_unused_result attribute. Even though the attached patch tcmalloc_gcc44.txt can fix these build errors, I would like to ask experts here since this is a third_party library and I cannot change it. (I don't have any good idea to fix unittest_utils.cc since vsnprintf() needs a define _BSD_SOURCE (or _ISOC99_SOURCE) on Linux.) I don't know about the unittest_utils.cc error, I'd have to look it up, but for the rest of them, here's probably the best thing to do right now: (1) The patch to tcmalloc_linux.cc is fine since it's already forked. (2) Fork all the .cc files that reference symbolize.h, add the inttypes.h include before the symbolize.h include. This seems to be symbolize.cc and heap-profile-table.cc (we don't use debugallocation.cc yet). We can't fix symbolize.h by forking it directly because the #include's will prefer the symbolize in the current directory, rather than the one you forked. See issue 27911 for a more complete explanation. sgk's fixing this. To fork it properly, add the new files in third_party/tcmalloc/ and make your edits there. Edit tcmalloc.gyp to add those two new sources, and make sure to subtract them from the windows build and subtract the old sources from the linux build. Yes, it's a mess. It'll get fixed soon. Regards
Re: [chromium-dev] Core Text
Greetings Jeremy, This is just for your information. It seems WebCore/platform/graphics/mac/ComplexTextControllerCoreText.cpp uses CTRunGetAdvancesPtr() and CTRunGetAdvances(), which are available only on 10.6 or later. (This might be a reason why WebKit doesn't use Core Text for Leopard?) (*1) http://developer.apple.com/mac/library/documentation/Carbon/Reference/CTRunRef/Reference/reference.html#//apple_ref/c/func/CTRunGetAdvancesPtr Best regards, Hironori Bono E-mail: hb...@chromium.org On Tue, Nov 24, 2009 at 6:17 AM, Jeremy Moskovich jer...@chromium.org wrote: Thanks Nico, I'll run some numbers. Best regards, Jeremy On Mon, Nov 23, 2009 at 11:15 PM, Nico Weber tha...@chromium.org wrote: Did you do measuring if it's actually slower on 10.5? The CoreText backend for MacVim is much faster than the ATSUI backend from what I've heard (then again, MacVim doesn't do very complex text rendering). (Source: http://groups.google.com/group/vim_mac/browse_thread/thread/b93c6dd5183bdc5e ) On Mon, Nov 23, 2009 at 12:58 PM, Jeremy Moskovich jer...@chromium.org wrote: Re http://crbug.com/27195 https://bugs.webkit.org/show_bug.cgi?id=31802 : Dan Bernstein says that Core Text on Leopard has performance issues vs ATSUI so I'm going to look into switching APIs at runtime rather than compile time. So we'd use ATSUI 10.6 Core Text = 10.6 . Best regards, Jeremy -- 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
[chromium-dev] [FYI] Build errors while building Chromium with gcc 4.4.
Greetings Chromium-developers,
(Please ignore this e-mail when you are not building Chromium with gcc 4.4.)
Today, a person reported gcc 4.4 yields the following build errors
while building Chromium on IRC:
cc1plus: error: dereferencing pointer '...' does break strict-aliasing rules
Unfortunately, gcc 4.4 checks the pointer conversion more strictly
than the previous gcc and it yields some warnings while compiling
chromium.
Even though it is definitely better to change our code to make it
compile with gcc 4.4, I would like to write a temporary workaround
that avoids these warnings.
1. Creating a file ~/.gyp/inclulde.gypi'.
2. Adding a following lines to the file.
{
'variables': {
'no_strict_aliasing': 1
}
}
3. Run gclient runhooks --force to re-build scons or make files.
4. Run hammer or make to re-build Chromium.
Regards,
Hironori Bono
E-mail: hb...@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] A Dictionary-Evaluation Plan
Greetings chromium-developers, (Please feel free to ignore this e-mail if you are not interested in our spell-checker and its dictionaries.) As you may know, we have updated hunspell used by Chromium to the latest version. It adds lots of features that improve its spell-checking quality (especially for non-English dictionaries.) To use these new features, we would like to update the dictionaries used by Chromium and support more spell-checker dictionaries. Nevertheless, we would like to evaluate the new dictionaries before releasing them to check their qualities, i.e. whether or not the new dictionaries are better than the old ones. Unfortunately, I don't have clear ideas for this evaluation, I would like to write my random thought and ask your opinions. Even though this is still a random thought, I would personally like to use chromium to evaluate the new dictionaries: i.e. uploading the new dictionaries to our dictionary server, changing the chromium code to use the updated ones, asking users to compare the new dictionaries with the old ones and give us their feedbacks (*1). If users like the new dictionaries, we would like to release the new ones. Otherwise we will keep the old ones. (*1) I don't have clear ideas how to get feedbacks, it may be good to use Google Spreadsheet? Since this is just my random thought to start a discussion, any comments and suggestions are definitely welcome. Would it be possible to give me your opinions? Best regards, Hironori Bono E-mail: hb...@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] Re: A Dictionary-Evaluation Plan
Hi Evan, Thank you for your feedback. 2009/10/28 Evan Martin e...@chromium.org: It still might be worth soliciting feedback from users directly. For example, if the new dictionary is missing a common word the above measure would get a high count of Add to Dictionary, and maybe users could tell us about this. Counting a common word is a good option for English. On the other hand, I'm wondering how much this idea works for case languages, such as Russian, Polish, etc. For example, a Russian noun has six cases (nominative, accusative, genitive, prepositional, and instrumental) and each noun changes its form according to the case and number. For example, a masculine noun стол (table) has six forms: стол, стол, стола, столу, столе, and столом. If a noun is countable, its plural form столы (tables) also has six forms: столы, столы, столов, столам, столах, столами. So, when we count each form as a separated dictionary word, the frequency count of a Russian word statistically (*1) becomes 1/6 of an English word. To write more about Russian, a Russian noun has three genders (masculine, feminine, and neutral) and each adjective has to change its form according to the gender and the case of a noun being qualified. That is, the frequency count of a Russian adjective statistically becomes 1/(3*6) = 1/18 of an English adjective. (This is a reason why our ru_RU.dic_delta file doesn't have adjectives.) If we can add an option menu so that a user can choose such grammatical information when the user adds a word, it definitely helps. (*1) In reality, some cases (nominative) are used more often than other cases. Regards, Hironori Bono E-mail: hb...@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] Re: Tab Thumbnails and Aero Peek (of Windows 7)
Hi Brett, Thank you for your suggestions. I would like to use the default size and resize it in my code that creates tab thumbnails. Regards, Hironori Bono E-mail: hb...@chrommium.org 2009/10/24 Brett Wilson bre...@chromium.org: 2009/10/23 Hironori Bono (坊野 博典) hb...@google.com: Hi Brett, Thank you so much for noticing this. I'm integrating the ThumbnailGenertor class into my prototype now. :) By the way, I'm a little wondering if there is a function that changes the width and the height of a thumbnail image generated by the ThumbnailGenerator class at run time. If not, I would like to hear there is a plan to add it. When Windows 7 shows tab thumbnails, it automatically calculates the width and the height of a thumbnail image so that it can show all thumbnails in one line. (When we open too many tabs and Windows 7 cannot show their thumbnails, it shows a list of tab titles.) In brief, we cannot assume the width or the height of a thumbnail as constant values on Windows 7. So, it may be better for the ThumbnailGenerator class to have an interface that changes the width and the height of its thumbnails. (I has added code that resizes the thumbnails retrieved from the ThumbnailGenerator object and sends the resized thumbnails to Windows 7. So, I don't mind it at all.) There isn't a way to do this. The reason is that the thumbnail generator precalculates thumbnails in advance for many pages (for example, when we're discarding the backing store). This means we have to know basically when we start Chrome what the max thumbnail size will be. It uses power-of-two downsampling to be as fast as possible, so the actual thumbnails aren't guaranteed to be any particular size. I would just use the default size for now. If it doesn't look OK, we can add a future enhancement to request the size, so the ones it generates on-demand (the ones where there is a backing store) can have a larger size if needed. Brett --~--~-~--~~~---~--~~ 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: Tab Thumbnails and Aero Peek (of Windows 7)
Hi Mike, Thank you for your question and suggestion. On Sat, Oct 24, 2009 at 2:19 AM, Mike Pinkerton pinker...@chromium.org wrote: All the screenshots show this with a single window. What happens if you have multiple windows open? Does it only show the selected window? Unfortunately, the current prototype just shows the thumbnails of the all Chromium windows. I realize many users like to see only the thumbnails of the selected window and would like to implement it. Nevertheless, to show only the thumbnails of the selected window, we probably need to handle more events than the ones handled by the current prototype (such as detaching a tab, attaching a tab, creating a popup window, creating a dialog, etc.) and choose the window to which a tab (a pop-up window, or a dialog) belongs. Unfortunately, my current prototype is still an infant phase and it is not good time to implement such complicated logics. As an alternate suggestion, we have a mode in Camino2 called tabspose which is like OS X Expose, but shows the (large) thumbnails of all open tabs overlaying the content area of the browser. Allows much better visualization of the tabs because you're not limited to small squares but can use as much of the window as available. This does involve interacting with the window already, so it doesn't work until you have the window in the foreground, but I wanted to bring it up as an idea. http://www.flickr.com/photos/spaunsglo/987375693/ for an early screenshot (currently looks more polished, but same idea). Thank you for your link. I'm going to look into it. :) Regards, Hironori Bono E-mail: hb...@chromium.org 2009/10/23 Brett Wilson bre...@chromium.org: 2009/10/23 Hironori Bono (坊野 博典) hb...@google.com: Hi Brett, Thank you so much for noticing this. I'm integrating the ThumbnailGenertor class into my prototype now. :) By the way, I'm a little wondering if there is a function that changes the width and the height of a thumbnail image generated by the ThumbnailGenerator class at run time. If not, I would like to hear there is a plan to add it. When Windows 7 shows tab thumbnails, it automatically calculates the width and the height of a thumbnail image so that it can show all thumbnails in one line. (When we open too many tabs and Windows 7 cannot show their thumbnails, it shows a list of tab titles.) In brief, we cannot assume the width or the height of a thumbnail as constant values on Windows 7. So, it may be better for the ThumbnailGenerator class to have an interface that changes the width and the height of its thumbnails. (I has added code that resizes the thumbnails retrieved from the ThumbnailGenerator object and sends the resized thumbnails to Windows 7. So, I don't mind it at all.) There isn't a way to do this. The reason is that the thumbnail generator precalculates thumbnails in advance for many pages (for example, when we're discarding the backing store). This means we have to know basically when we start Chrome what the max thumbnail size will be. It uses power-of-two downsampling to be as fast as possible, so the actual thumbnails aren't guaranteed to be any particular size. I would just use the default size for now. If it doesn't look OK, we can add a future enhancement to request the size, so the ones it generates on-demand (the ones where there is a backing store) can have a larger size if needed. Brett -- 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] Tab Thumbnails and Aero Peek (of Windows 7)
Greetings Chromium developers, (Please feel free to ignore this e-mail if you are not interested in Windows 7.) To celebrate the launch of Windows 7, I have written a document that describes my prototype implementation that integrates Tab Thumbnails and Aero Peek into Chromium. (My current prototype has some problems, though.)Your comments and suggestions are definitely welcome. Sorry for sending a huge e-mail in advance. Regards, Hironori Bono E-mail: hb...@chromium.org *Tab Thumbnails and Aero Peek* Objective This document is a report of my prototype implementation that integrates two new features of Windows 7 (Tab Thumbnails and Aero Peek) into Chromium. Background Windows 7, the new operating system from Microsoft, has added some new features to its taskbar[1]file:///C:/Users/hBono/Documents/Google/Chrome/Tab%20Thumbnails%20and%20Aero%20Peek.docx#_ftn1: JumpList, Tab Thumbnails, Aero Peek, etc. Among these new features, Tab Thumbnails and Aero Peek are designed for improving the user experiences of TDI (Tab-Document-Interface) applications. In fact, users want for Chrome to support them and filed an issue to our buganizer (Issue 6337[2]file:///C:/Users/hBono/Documents/Google/Chrome/Tab%20Thumbnails%20and%20Aero%20Peek.docx#_ftn2 ). * What are Tab Thumbnails and Aero Peek?* In Windows 7, an application can add (or remove) thumbnails for each application so that hovering over its taskbar button to display them as shown in Figure 1. Each thumbnail can have its own title and icon. (A thumbnail can also have its own buttons even though this example doesn’t use them.) The focused tab is shown as a high-lighted thumbnail in this thumbnail list. Figure 1 Tab Thumbnails As shown in Figure 2, hovering a mouse cursor onto a thumbnail shows the preview image of the corresponding tab, and clicking a thumbnail selects the tab, respectively. (This feature is called as Aero Peek.) Figure 2 Aero Peek Also, clicking the close button of a thumbnail (shown at the top-right corner of the focused thumbnail) closes the corresponding tab. Figure 3 Close button of a thumbnail * * Implementing Tab Thumbnails and Aero Peek Unfortunately, without using new APIs provided by Windows 7, Windows 7 just shows the thumbnail of the application window. This section provides a generic overview about implementing Tab Thumbnails and Aero Peek. (The information in this section is just the result of my investigation, and maybe incorrect.) How to add a custom thumbnail? At first, we need to add a custom thumbnail to the Tab-Thumbnail list of Windows 7. To add a custom thumbnail, we need a (tool) window[3]file:///C:/Users/hBono/Documents/Google/Chrome/Tab%20Thumbnails%20and%20Aero%20Peek.docx#_ftn3that receives messages from Windows 7. Windows 7 sends the following messages to notify thumbnail-specific events. So, we need to create a place-holder window that handles these events for each tab. 1.* WM_CREATE (0x0001) This message is sent when a window has been created. An application has to call DwmSetWindowAttribute() to notify Windows 7 that this window can handle WM_DWMSENDICONICTHUMBNAIL and WM_DWMSENDICONICLIVEPREVIEWBITMAP messages[4]file:///C:/Users/hBono/Documents/Google/Chrome/Tab%20Thumbnails%20and%20Aero%20Peek.docx#_ftn4. Also, an application needs to call ITaskbarList3::RegisterTab() to add this window to the Tab-Thumbnail list of an application[5]file:///C:/Users/hBono/Documents/Google/Chrome/Tab%20Thumbnails%20and%20Aero%20Peek.docx#_ftn5 . 2.* WM_ACTIVATE (0x0006) This message is sent when a user clicks the thumbnail image to select its corresponding tab. 3.* WM_CLOSE (0x0010) This message is sent when a user clicks the close button of a thumbnail. An application has to call ITaskbarList3::UnregisterTab() to remove this window from the Tab-Thumbnail list before calling DestroyWindow(). 4.* WM_DWMSENDICONICTHUMBNAIL (0x0323) This message is sent when Windows 7 needs the thumbnail image of the corresponding tab. An application has to create a thumbnail bitmap (whose size is given as the LPARAM parameter of this message[6]file:///C:/Users/hBono/Documents/Google/Chrome/Tab%20Thumbnails%20and%20Aero%20Peek.docx#_ftn6) and send it to Windows 7 through a DwmSetIconicThumbnail() call. (Windows 7 shows a “loading” animation before sending a bitmap to Windows 7.) 5.* WM_DWMSENDICONICLIVEPREVIEWBITMAP (0x0326) This message is sent when Windows 7 needs the preview image of the corresponding tab. An application has to create a preview bitmap and send it to Windows 7 through a DwmSetIconicLivePreviewBitmap() call. How to update the thumbnail image of a tab? Windows 7 can send WM_DWMSENDICONICTHUMBNAIL messages to a place-holder window when it needs its thumbnail image. On the other hand, when an application needs to update the thumbnail image of a tab, it has to call DwmInvalidateIconicBitmaps() and let Windows 7 send a WM_DWMSENDICONICTHUMBNAIL message. It makes Windows 7 unhappy and usually
[chromium-dev] Re: Layout tests can now be run on both XP and Vista
Hi Dirk, Thank you so much for your great work! By the way, I have been using XP Mode of Windows 7 (*1) to run layout tests since I changed my development PC to Windows 7. (It's not so fast, but it's OK.) Does this Win7 baselines mean we don't need to use XP Mode? (I assume yes.) (*1) http://www.microsoft.com/windows/virtual-pc/ Sorry for my stupid question in advance. Regards, Hironori Bono E-mail: hb...@chromium.org On Tue, Sep 15, 2009 at 8:26 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I have just landed a patch that enables us to run layout tests on Vista as well as XP. In theory, you should continue to use the tools just as you have in the past, and everything will work transparently. In practice, I may have screwed up something, so if you notice problems please let me know. One important change is that we now have a few XP-specific baselines in webkit/data/layout_tests/platform/chromium-win-xp (mostly in the way we handle various international characters and font differences between XP and Vista). We do not have any Vista-specific baselines (although one could argue that if there is a baseline in chromium-win and a baseline in chromium-win-xp then the chromium-win one is Vista-specific). We will be following the WebKit convention that the generic platform directory represents the most recent version of the platform (meaning that until Win 7 is released, all Vista baselines go in chromium-win. When Win 7 is released, Vista-specific baselines will go in chromium-win-vista). In practice, this means you might need to be careful about where your new baselines end up when using the rebaselining tool. You should make sure they end up in chromium-win unless you are sure they are XP-specific (in which case you will be responsible for landing baselines for both XP and Vista). If you have any questions about this, or run into problems, please let me know ASAP. One last thing for those who might look at this stuff in detail - test_shell has been changed to use a generic theme for rendering form controls, scroll bars, and other native widgets, in order to not have any differences from the different themes on the different versions of Windows. If you are wondering why the scroll bars and other controls in the baselines look really odd, that's why. Also, the checkin involved updating 700 images, so I didn't have anyone but me review them. Let me know if you see anything that doesn't look right :) Also, we will probably be landing Win 7 baselines Real Soon Now, since adding them is a very small additional amount of work on top of the stuff I just landed. Cheers, -- Dirk --~--~-~--~~~---~--~~ 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: Linking Failed by Conflict Class IDs in jumplist.cc
Thank you for your report and sorry for your inconvenience. I'm going to rename the symbol names to avoid conflicts with VS2008. Regards, Hironori Bono E-mail: hb...@chromium.org. On Sat, Aug 1, 2009 at 12:57 PM, mhtmhsien.t...@gmail.com wrote: Hi all, I have a link error when building Chromium source code, error message as below: uuid.lib(shguids2.obj) : error LNK2005: _CLSID_DestinationList already defined in browser.lib(jumplist.obj) uuid.lib(shguids2.obj) : error LNK2005: _CLSID_EnumerableObjectCollection already defined in browser.lib (jumplist.obj) Build environment: - Windows SDK 6.1 (setenv.cmd /Debug /x86 /Vista) - Visual Studio 2008 SP1 - lib env variable: lib=E:\Vista_App\VS90\VC\Lib;E:\Microsoft SDKs \Windows\v6.1\Lib;E:\Vista_App\VS9 0\VC\ATLMFC\LIB;E:\Vista_App\VS60\VC98\mfc\lib;E:\Vista_App \VS60\VC98\lib Comment out the two class id definitions in jumplist.cc, then the build succeeded. Even though these two Class IDs were defined in anonymous namespace, it still have conflict. Is there any better solution before phase in Windows SDK 7.0? BR, mht --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
Hi Ukai-san,
ViewHostMsg_WebSocket*: IPC messages sent from renderer to browser.
ViewHostMsg_WebSocketOpen: open a new Web Socket. called by
WebSocketHandle::connect().
int request_id // idenfity WebSocket object {GURL url, std::wstring
protocol, std::wstring origin, bool secure, [...]}
ViewHostMsg_WebSocketSend: trasmit a frame containing data over the Web
Socket connection. called by WebSocketHandle::send().
int request_id // Identify WebSocket object
std::vectorunsigned char data
ViewHostMsg_WebSocketDisconnect: disconnect the Web Socket connection. called
by WebSocketHandle destructor.
int request_id // Identify WebSocket object
ViewMsg_WebSocket*: IPC messages sent from browser to renderer.
ViewMsg_WebSocketConnect: New Web Socket connection is established. will call
WebSocketHandle::client()-didConnect().
int request_id // Identify WebSocket object
ViewMsg_WebSocketRecv: a frame containing data is received on the Web Socket
connection. will add data into WebSocketHandle::bufferedData(). Process
all complete Web Socket frames, call WebSocketHandle::client()-didReceive().
int request_id // Identify WebSocket object
std::vectorunsigned char data
ViewMsg_WebSocketClose: the Web Socket connection is closed (on the other
side). will call WebSocketHandle::client()-didClose().
int request_id // Identify WebSocket object
I'm a little wondering whether these messages are async messages or
sync ones. Is it possible to add notes about their message types?
Regards,
Hironori Bono
E-mail: hb...@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] Re: Fixing our keyboard handling act on OSX
Hi Jeremy, It is not a problem at all. Thank you for notifying this. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/6/9 Jeremy Moskovich jer...@chromium.org: Hi Hironori, Upon further reflection, I'm concerned about some of the fixes around these issues interacting badly with the Cocoa restructuring work I'm doing. Could you hold off on the OSX side of the changes till the end of the month to give me time to transition the Mac infrastructure to work better with Cocoa? Best regards, Jeremy 2009/6/7 Jeremy Moskovich jer...@chromium.org Hi Hironori, Thanks for the detailed report. I haven't nearly the same insight into the text input system as you and Avi do, but from what I've seen it may be possible for us to do at least a marginally better job using the built-in system routines and thus avoiding many sticky bugs e.g. http://crbug.com/10862 - OS X: Can't use command-key shortcuts with foreign keyboard layouts should be fixed by a CL I'm working on at the moment. The solution is to go through the native Cocoa methods to have the menu item fire the appropriate objc selector on the RHWV rather than trying to process the raw keystroke in the renderer process. I also think we can get Cocoa to translate emacs editing commands (such as cntrl-a) into the appropriate WebKit editor commands for us. Best regards, Jeremy 2009/6/5 Hironori Bono (坊野 博典) hb...@chromium.org Hi Jeremy, et al, Sorry for my slow update. This is the draft report of my investigation that implements the NSTextInput protocol on Mac, implements the GtkIMContext on Linux and observes keyboard events on Windows, Mac, and Linux. (Sorry, I would like to send it as a PDF file because the google site somehow compresses its figures too much to make its characters unreadable.) Since I'm still finding the best solutions for the issues, any comments and suggestions are definitely welcome. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/5/29 Hironori Bono (坊野 博典) hb...@chromium.org: Hi Jeremy, I have been investigating keyboard events on Windows, Linux, and Mac to find solutions for these issues. Shall we have a discussion about these issues when I finish writing my report (maybe sometime next week)? Regards, Hironori Bono E-mail: hb...@chromium.org On Thu, May 28, 2009 at 7:14 AM, Jeremy Moskovich jer...@chromium.org wrote: Hi All, We currently fudge our keyboard handling on OSX, we interpret command key shortcuts ourselves and thus miss out on quite a few Cocoa text handling niceities. We also don't support IMEs. Relevant bugs: http://crbug.com/10862 - OS X: Can't use command-key shortcuts with foreign keyboard layouts http://crbug.com/12698 - standard macintosh text editing keyboard shortcuts are missing http://crbug.com/11981 - Deadkeys do not work http://crbug.com/11952 - IME support (Chinese input method doesnt work) We also don't handle activation/deactivation of edit menu items correctly (select all is always disabled). I've done a little digging in WebKit's keyboard handling and what follows is a proposal on how we can more closely match the OSX keyboard handling code and [hopefully] do things the right way. I don't purport to understand this all and there may be simpler ways to achieve this so feel free to comment. Standard commands (Copy/Paste/Select-all): WebKit handles these through the regular obj-c selectors in WebHTMLView, see the WEBCORE_COMMAND macro. We could do the same thing and add these selectors to BrowserWindowController which would then send an IPC message over to the renderer process to execute the appropriate command. The tricky bit is updating the menus, the model in Cocoa is for the OS to call you for each menu item before displaying a menu. We can't block the browser process on the renderer process so the browser process would always need to know if there is an active selection. WebCore appears to already have a mechanism to do this via notifyAccessibilityForSelectionChange() - we could use the same or a similar mechanism to send an IPC message back to the browser process each time the selection changes. Emacs keyboard commands and IMEs: The IME part of the title may be nonsense, but looking at the code it appears the code path and issues are the same. I've attached the stack trace for hitting cntrl-t to the end of this email. The tricky bit here is that WebCore is first given a shot at handling the event and then passes it back to WebHTMLView to take another look at the event which is where it's actually parsed. I assume this is to give JS code a chance to listen on these events. Since we can't serialize an NSEvent, we can't replicate this code solely in the renderer. A possible solution to this would be to store a queue of the last N NSEvents per renderer matched with an ID. the event
[chromium-dev] Re: Fixing our keyboard handling act on OSX
Hi Nico, Thank you for your comment and sorry for confusing you. 2009/6/6 Nico Weber tha...@chromium.org: Hi, re Type ctrl-a on hebrew keyboard: On OS X, ctrl-a usually does not select all text (that's what cmd-a does) but goes to the beginning of the current line, as in emacs. But that can be overridden ( http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html ). Yes, we noticed this control+a key should move the input cursor at the beginning of a line on Mac. Nevertheless, this issue happens also on US keyboards. The purpose of this discussion is: how we should handle non-US keyboards as well as US keyboards, so, the expected behavior for this control+a case is the one when we type the control+a keys on a US keyboard even though this is not expected behavior of Mac OS X. Mac people, Is it possible to give me whether or not there are any bugs filed to our buganizer for this shortcut-incompatibility issue? Regards, Hironori Bono E-mail: hb...@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] Re: Fixing our keyboard handling act on OSX
Hi James Su, Thank you for your comments. On Sat, Jun 6, 2009 at 1:17 AM, Zhe Sujames...@gmail.com wrote: Hi, I'm interested in working with you on the IME support issue, especially on Linux. I just read attached document, and following are some of my questions and information: 1. How about the support of on-the-spot mode (preedit/composition) and surrounding text? Which require more events than key press/release and commit. As I know that some of input methods (at least on Linux) rely on these features. 2. On Linux/Gtk, some input methods (like SCIM) will intercept key events by using gtk_key_snooper_install(), so that when input method is on, only key events that are not handled by input method will be delivered to application. Which might lead problem if application relies on those key events to work. Thank you for your comments. They are definitely helpful. To handle IME events on Linux (GTK), we notice we should not only handle more events of GTKIMContext (e.g. preedit_start, preedit_changed, preedit_end, etc.) but also decide what IPC messages we should send when an IME intercepts key events. I'm adding more diagrams that describe such CJK cases (on Windows, Mac, and Linux) to my document so that we can also figure out CJK problems and find solutions that make all platforms happy. I'm sure we should keep you informed about this issue, so it is helpful to keep giving us your comments and suggestions. Regards, Hironori Bono E-mail: hb...@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] Re: Please ping me if you plan on touching the OSX keyboard handling code
Hi Jeremy, Sure. I have been adding code to implement the NSTextInput interface (mainly in chrome/browser/renderer_host/render_widget_host_view_mac.mm). If it becomes OK, I'm going to notice you. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/6/3 Jeremy Moskovich jer...@chromium.org: We have a bunch of bugs around keyboard handling on OSX since we currently bypass the Cocoa event handling system. I've started to look into some of these issues. Please touch bases with me if you plan on touching the event code on OSX. Duplicating work really sucks. Thanks, Jeremy --~--~-~--~~~---~--~~ 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: Fixing our keyboard handling act on OSX
Hi Jeremy, I have been investigating keyboard events on Windows, Linux, and Mac to find solutions for these issues. Shall we have a discussion about these issues when I finish writing my report (maybe sometime next week)? Regards, Hironori Bono E-mail: hb...@chromium.org On Thu, May 28, 2009 at 7:14 AM, Jeremy Moskovich jer...@chromium.org wrote: Hi All, We currently fudge our keyboard handling on OSX, we interpret command key shortcuts ourselves and thus miss out on quite a few Cocoa text handling niceities. We also don't support IMEs. Relevant bugs: http://crbug.com/10862 - OS X: Can't use command-key shortcuts with foreign keyboard layouts http://crbug.com/12698 - standard macintosh text editing keyboard shortcuts are missing http://crbug.com/11981 - Deadkeys do not work http://crbug.com/11952 - IME support (Chinese input method doesnt work) We also don't handle activation/deactivation of edit menu items correctly (select all is always disabled). I've done a little digging in WebKit's keyboard handling and what follows is a proposal on how we can more closely match the OSX keyboard handling code and [hopefully] do things the right way. I don't purport to understand this all and there may be simpler ways to achieve this so feel free to comment. Standard commands (Copy/Paste/Select-all): WebKit handles these through the regular obj-c selectors in WebHTMLView, see the WEBCORE_COMMAND macro. We could do the same thing and add these selectors to BrowserWindowController which would then send an IPC message over to the renderer process to execute the appropriate command. The tricky bit is updating the menus, the model in Cocoa is for the OS to call you for each menu item before displaying a menu. We can't block the browser process on the renderer process so the browser process would always need to know if there is an active selection. WebCore appears to already have a mechanism to do this via notifyAccessibilityForSelectionChange() - we could use the same or a similar mechanism to send an IPC message back to the browser process each time the selection changes. Emacs keyboard commands and IMEs: The IME part of the title may be nonsense, but looking at the code it appears the code path and issues are the same. I've attached the stack trace for hitting cntrl-t to the end of this email. The tricky bit here is that WebCore is first given a shot at handling the event and then passes it back to WebHTMLView to take another look at the event which is where it's actually parsed. I assume this is to give JS code a chance to listen on these events. Since we can't serialize an NSEvent, we can't replicate this code solely in the renderer. A possible solution to this would be to store a queue of the last N NSEvents per renderer matched with an ID. the event would then be serialized and sent to the renderer which could then send it's own IPC message back to the browser process to get Cocoa to handle the message, we could pick the NSEvent out of the queue by ID and send back the relevant edit command to the renderer. Since the events belong to a specific renderer a malicious renderer process can't access events not targeted at them. Best regards, Jeremy Stack trace of hitting cntrl-t (transpose) in a text view, Cocoa [browser-process] stuff marked in bold. #0 WebCore::executeTranspose (frame=0x70b9800) at /Users/Shared/playmobil/work/git.WebKit/WebCore/editing/EditorCommand.cpp:961 #1 0x03702f0f in WebCore::Editor::Command::execute (this=0xbfffe2f4, paramet...@0xbfffe2ac, triggeringEvent=0x24178380) at /Users/Shared/playmobil/work/git.WebKit/WebCore/editing/EditorCommand.cpp:1450 #2 0x037052ad in WebCore::Editor::Command::execute (this=0xbfffe2f4, triggeringEvent=0x24178380) at /Users/Shared/playmobil/work/git.WebKit/WebCore/editing/EditorCommand.cpp:1455 #3 0x0031d3da in -[WebHTMLView(WebNSTextInputSupport) doCommandBySelector:] (self=0x6cefe90, _cmd=0x943edca4, selector=0x94423fa4) at /Users/Shared/playmobil/work/git.WebKit/WebKit/mac/WebView/WebHTMLView.mm:5337 #4 0x0031c238 in -[WebHTMLView(WebInternal) _interceptEditingKeyEvent:shouldSaveCommand:] (self=0x6cefe90, _cmd=0x3a405c, event=0x24178380, shouldSave=0 '\000') at /Users/Shared/playmobil/work/git.WebKit/WebKit/mac/WebView/WebHTMLView.mm:4966 #5 0x002eb19b in WebEditorClient::handleKeyboardEvent (this=0x6c31aa0, event=0x24178380) at /Users/Shared/playmobil/work/git.WebKit/WebKit/mac/WebCoreSupport/WebEditorClient.mm:440 #6 0x036f8875 in WebCore::Editor::handleKeyboardEvent (this=0x70b9cd4, event=0x24178380) at /Users/Shared/playmobil/work/git.WebKit/WebCore/editing/Editor.cpp:105 #7 0x037156fb in WebCore::EventHandler::defaultKeyboardEventHandler (this=0x70b9d00, event=0x24178380) at /Users/Shared/playmobil/work/git.WebKit/WebCore/page/EventHandler.cpp:1907 #8 0x03a7876e in WebCore::Node::defaultEventHandler (this=0x1c23f430, event=0x24178380) at
[chromium-dev] Re: Fixing our keyboard handling act on OSX
Avi, On Fri, May 29, 2009 at 5:45 AM, Avi Drissman a...@chromium.org wrote: We already do much of this. Take a look at TabContentsViewMac::HandleKeyboardEvent, where ids referring to keyboard events not handled by WebKit are returned to the browser process. TabContentsViewMac then retrieves the original event and passes it up to Cocoa for handling. That might be an opportune time to Do The Right Thing. How do IMEs belong here? In Mac (Cocoa) (*1), IME events are sent through the NSTextInput interface. So, we need to implement the interface to support IMEs. I have added a mock implementation to monitor IME events on Mac. (This implementation is still in an infant phase, though.) (*1) I assume we don't have to support Carbon, right? In Linux, IME events are sent though GtkIMContext signals as well as some keyboard events from non-US keyboards, e.g. dead keys, etc. As I wrote in my previous reply, I have been monitoring all keyboard-related events including IME ones on Windows, Linux, and Mac to compare them side-by-side and find possible solutions. I hope I can send a report about my investigation sometime next week. Regards, Hironori Bono E-mail: hb...@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] Re: making UI tests pass in RTL (question)
yoav.zilberberg, You are right. Currently, we don't have good methods to retrieve the UI language from a UI Test (ui_tests.exe). I think it is useful to add a new AutomationMsg which retrieves the UI language of a running browser from a UI test. Regards, Hironori Bono E-mail: hb...@chromium.org On Fri, May 29, 2009 at 4:36 AM, nakro yoav.zilberb...@gmail.com wrote: just to make sure i got it straight : my code will be executing from the ui_tests.exe the browser is a different process This API you mentioned seems (i didn't check yet) to only work on the current process but imagine this : hbono suggested that there could be cases where the ui_test runs in one lang and the browser itself is invoked with another will this really tell me what direction the browser process is in ? which is what i need... --~--~-~--~~~---~--~~ 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: Tweaking DownloadManager
Hi Yuta, I just provided another possible option that solves Issue 3551 Download menu items should be disabled when downloaded file has been deleted and it is definitely up to you which option you take for solving this issue. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/5/27 Yuta Kitamura yu...@google.com: Hi Bono-san, Thanks for your response. I think your resolution has some problems: - There is a nasty timing issue; The user faces the same problem if the user opens the menu, somebody deletes the file after that, and then the user clicks the menu item. - There is no way to know the reason why the menu is disabled. - You can still open the item by clicking the button (when should we disable it?). - chrome://downloads/ still has the problem. I feel that we need to display some feedback of ShellOpen. Opening a file without checking sounds horrible to me. Thanks, Yuta 2009/05/22 20:40 Hironori Bono (坊野 博典) hb...@chromium.org: Hi Yuta, I suspect it is simpler to change DownloadShelfContextMenu::IsItemCommandEnabled() and enable its open and show in folder items only when the downloaded file exists as shown in my mock code http://codereview.chromium.org/113805. (Even though this mock code is not tested thoroughly and may cause side-effects, please feel free to copy and use it.) Regards, Hironori Bono E-mail: hb...@chromium.org On Sat, May 23, 2009 at 10:47 AM, Yuta Kitamura yu...@google.com wrote: Hi all, I've been researching on DownloadManager for a day in order to to fix the issue 3551 http://crbug.com/3551. I want to hear some advice from people who know Chrome's design well. The problem of this issue is like the following: DownloadManager::OpenDownloadInShell() posts a task that opens a file using the shell (ShellExecute()) to the file thread. Because this task does not return any response (i.e. whether open was successful or not) back to the UI thread, DownloadItem cannot receive the result of open and the browser UI cannot display it either. So, I want to add the functionality of receiving the result of opening a file to DownloadItem. My current idea of implementation is: 1. Let DownloadItem be RefCountedThreadSafe, and rewrite use of DownloadItem* to scoped_refptrDownloadItem. 2. Add the interface of receiving the result of OpenDownloadInShell to DownloadItem. Modify DownloadFileManager::OnOpenDownloadInShell to pass the result to it. 3. Modify UI (DownloadItemView) to reflect these changes. 4. Write tests. My question is: - How do you think about the whole idea? Am I going the right way? - Step 1: Is it okay to do this? Will this change give the negative effect of the browser's speed? - Step 3: How should the UI look like? - Step 4: How to do it? Is there a good reference in the existing tests? (Sorry but I'm not very experienced on testing...) How do you think? Any idea and suggestion is welcome! Thanks, Yuta --~--~-~--~~~---~--~~ 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: Tweaking DownloadManager
Hi Yuta, I suspect it is simpler to change DownloadShelfContextMenu::IsItemCommandEnabled() and enable its open and show in folder items only when the downloaded file exists as shown in my mock code http://codereview.chromium.org/113805. (Even though this mock code is not tested thoroughly and may cause side-effects, please feel free to copy and use it.) Regards, Hironori Bono E-mail: hb...@chromium.org On Sat, May 23, 2009 at 10:47 AM, Yuta Kitamura yu...@google.com wrote: Hi all, I've been researching on DownloadManager for a day in order to to fix the issue 3551 http://crbug.com/3551. I want to hear some advice from people who know Chrome's design well. The problem of this issue is like the following: DownloadManager::OpenDownloadInShell() posts a task that opens a file using the shell (ShellExecute()) to the file thread. Because this task does not return any response (i.e. whether open was successful or not) back to the UI thread, DownloadItem cannot receive the result of open and the browser UI cannot display it either. So, I want to add the functionality of receiving the result of opening a file to DownloadItem. My current idea of implementation is: 1. Let DownloadItem be RefCountedThreadSafe, and rewrite use of DownloadItem* to scoped_refptrDownloadItem. 2. Add the interface of receiving the result of OpenDownloadInShell to DownloadItem. Modify DownloadFileManager::OnOpenDownloadInShell to pass the result to it. 3. Modify UI (DownloadItemView) to reflect these changes. 4. Write tests. My question is: - How do you think about the whole idea? Am I going the right way? - Step 1: Is it okay to do this? Will this change give the negative effect of the browser's speed? - Step 3: How should the UI look like? - Step 4: How to do it? Is there a good reference in the existing tests? (Sorry but I'm not very experienced on testing...) How do you think? Any idea and suggestion is welcome! Thanks, Yuta --~--~-~--~~~---~--~~ 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: Question on Window's CRichEditCtrl, SetParaFormat, and IME
Hi Xiaomei, Sorry for the lack of my responses. It seems a known issue of a RichEdit control (*1), which automatically changes its keyboard layout with the current selection. When I create a simple MFC application which just shows a dialog including a RICHEDIT20 control, it also changes its keyboard layout automatically on my Vista PC. (*1) http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/b640e764-0c3c-43fc-a670-4c5e73167ce4/ I'm also trying possible solutions for this issue now. Regards, Hironori Bono E-mail: hb...@chromium.org On Tue, May 12, 2009 at 12:19 PM, xji x...@chromium.org wrote: I have one question might be related to MFC's CRichEditCtrl and SetParaFormat, and I would appreciate any input. TextField::Edit is derived from CWindowImplTextField::Edit, CRichEditCtrl, CWinTraitskDefaultEditStyle . Currently, in RTL UI (for example, Hebrew Chrome), the TextField::Edit is initialized as right-aligned, but with left-to-right layout. I am trying to initialize the layout to be right-to-left in RTL UI and adjust the layout on the fly, which means, if the input text is a pure LTR text, the layout will be re-set as left-to-right; when there is RTL character in the text, the layout will be re-set to right-to- left. (To make it simple, I will assume the text is not an URL, which should always have LTR directionality.) Resetting layout can be achieved by SetParaFormt(). But there is one problem that I could not figure out: If I type an English character 'a', the layout will be re-set to LTR. Then, I change the IME to Hebrew and type a Hebrew character, the layout will be re-set to RTL, and the Hebrew character is placed at the left side of 'a'. But the IME changed back to English. I have no idea why IME change back to English. And looks like it does not matter whether I initialize the TextField::Edit as LTR layout or RTL layout, after type in the first Hebrew character following the English character, the IME always change back to English. And if I switch the IME to Hebrew again and type in 2nd or more Hebrew character, the IME will stay as Hebrew. I'd appreciate if anyone has any idea on what is going on and why. Thanks, Xiaomei Reply Forward --~--~-~--~~~---~--~~ 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: [chromium-reviews] A quick fix for Issue 2215....
Hi Elliot, Thank you for your response and analysis. My UI test just calls the SimulateOSKeyPress() function to send a keyboard event to a test page which contains a onkeydown event handler, and GetActiveTabTitle() to retrieve the tab name. Anyway, I'm going to divide this change into a code change and a test. When I confirm the test works on a try bot, I will send another review request. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/3/27 Elliot Glaysher e...@google.com: I am not sure you can write a normal UI test that uses SimulateOS*. (I know you can't do mouse clicks). This is because the windows screen needs to be unlocked for those commands to work so it will appear to pass locally but not on the buildbot. Perhaps this test should be in interactive_ui_tests, which is set up for tests that simulate OS events? -- Elliot On Thursday, March 26, 2009, Hironori Bono (坊野 博典) hb...@chromium.org wrote: Chromium-developers, Sorry for my stupid question. I'm writing a fix for Issue 2215 and its UI test to verify a DOM event sent when we press a VK_MENU key, which is uploaded into Rietveld (*1). Even though this UI test works fine on my PCs, it always fails on a try bot. (*1) http://codereview.chromium.org/42500/show To analyze the failure log listed below, it seems a DOM event is not sent to my onkeydown handler even when I send a keyboard event with a WindowProxy::SimulateOSKeyPress() call. Would it be possible to give me any hints why my UI test fails on a try bot? [--] 1 test from InputTest [ RUN ] InputTest.ModifierKeys ..\..\browser\input_uitest.cc(46): error: Value of: GetActiveTabTitle() Actual: LKeyCode Test Expected: LSUCCEEDED ..\..\browser\input_uitest.cc(46): error: Value of: GetActiveTabTitle() Actual: LKeyCode Test Expected: LSUCCEEDED ..\..\browser\input_uitest.cc(46): error: Value of: GetActiveTabTitle() Actual: LKeyCode Test Expected: LSUCCEEDED [ FAILED ] InputTest.ModifierKeys (61250 ms) [--] 1 test from InputTest (61250 ms total) Regards, Hironori Bono E-mail: hb...@chromium.org -- Forwarded message -- From: a...@chromium.org Date: Wed, Mar 25, 2009 at 10:31 PM Subject: Re: A quick fix for Issue 2215 To: hb...@chromium.org Cc: chromium-revi...@googlegroups.com With changes, lgtm. I don't know UI tests well, and don't know why this might fail. You might want to ask the list for their thoughts. http://codereview.chromium.org/42500/diff/28/2017 File chrome/browser/input_unittest.cc (right): http://codereview.chromium.org/42500/diff/28/2017#newcode1 Line 1: // Copyright (c) 2006-2008 The Chromium Authors. All rights reserved. Fix the copyright date; 2009. http://codereview.chromium.org/42500/diff/28/2017#newcode1 Line 1: // Copyright (c) 2006-2008 The Chromium Authors. All rights reserved. This file has a bad name. UI tests are named xxx_uitest.cc; see the vcproj to see examples. http://codereview.chromium.org/42500 --~--~-~--~~~---~--~~ 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: Writing tips to our build instructions?
Thank you all those who updated the build instructions. Regards, Hironori Bono E-mail: hb...@chromium.org On Wed, Feb 18, 2009 at 3:09 AM, Evan Martin e...@chromium.org wrote: On Tue, Feb 17, 2009 at 9:37 AM, Pam Greene p...@chromium.org wrote: And I've updated http://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code to make the make sure the path has no spaces note apply to all platforms rather than only Windows. (Is it true for Linux too?) It would surprise me if it mattered, but it also surprises me it matters on Win/Mac. Can't hurt, I guess. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
