[chromium-dev] Re: Readability mode prototyped in the wild
If a heuristic can judge the accuracy, then this readbility mode could be offered as a hint in some part of the screen (top or bottom right, similar to popup blocker does/used to do?). Otherwise there is an option for a fallback solution. Look at Aardvark (firefox plugin, https://addons.mozilla.org/en-US/firefox/addon/4111). Basically it shows a frame around different HTML block elements, and allows you to Isolate or Remove etc until you have the main article left in there. But maybe all of this still should go as an extension, rather than be built into Chrome? Basically the readability mode would weed out third party content, and some local stuff as well, leading to less ad exposure. The latter might not be enough politically correct to have as a default browser feature? On Mar 4, 11:08 pm, Mike Beltzner beltz...@mozilla.com wrote: On 4-Mar-09, at 4:38 PM, Evan Martin wrote: Here's the core of that implementation: http://lab.arc90.com/experiments/readability/js/readability-0.1.js It's heuristic-based, e.g.: // Study all the paragraphs and find the chunk that has the most p's and keep it: For what it's worth, there are several reports on LifeHacker that the selected heuristic doesn't end up working for a lot of pages, but it's a clever start, to be sure. I continue to feel that this is a huge use case for browsers and something like this could be a major boon if the UI was right. Agreed. I think you'd need clearer controls about how to get back to the full page, and probably a smooth transition from full page to selected bit that uses visual momentum to keep the user's context. Something similar to how the lightboxes on many websites use now, but perhaps without the 3-d effect. Also, it might be powerful to let the user indicate the aspect of the page they want to focus on. 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] Mac builds crash on every page
This morning's Mac build is a train wreck :( Every tab crashes while loading. [52334:19459:1323448372606907:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)] pipe error: Bad file descriptor [52334:19459:1323448373087271:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)] pipe error: Bad file descriptor [52334:19459:1323448373829541:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)] pipe error: Bad file descriptor [52334:19459:1323448378028354:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)] pipe error: Bad file descriptor [52335:2055:1323448378336616:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(386)] pipe error (3): Operation not permitted [52334:19459:1323448378479984:WARNING:/Users/pinkerton/src/trunk/src/chrome/common/file_descriptor_set_posix.cc(17)] FileDescriptorSet destroyed with unconsumed descriptors [52334:19459:1323448378507560:WARNING:/Users/pinkerton/src/trunk/src/chrome/common/file_descriptor_set_posix.cc(17)] FileDescriptorSet destroyed with unconsumed descriptors It was ok yesterday afternoon. Does this look familiar to anyone? Anyone know something that went in that might affect IPC channels? None of that code appears to have changed in at least a week. -- 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: Readability mode prototyped in the wild
I think I'd personally prefer the other page elements to remain in place, but have their brightness dimmed down (the way Youtube/Hulu/etc. have a turn down the lights feature - perhaps this is what Mike meant by lightboxes?). For this to work well it would probably also have to stop running flash elements similar to the flashkiller firefox addon. On Thu, Mar 5, 2009 at 5:03 AM, Simon simon.boh...@gmail.com wrote: If a heuristic can judge the accuracy, then this readbility mode could be offered as a hint in some part of the screen (top or bottom right, similar to popup blocker does/used to do?). Otherwise there is an option for a fallback solution. Look at Aardvark (firefox plugin, https://addons.mozilla.org/en-US/firefox/addon/4111). Basically it shows a frame around different HTML block elements, and allows you to Isolate or Remove etc until you have the main article left in there. But maybe all of this still should go as an extension, rather than be built into Chrome? Basically the readability mode would weed out third party content, and some local stuff as well, leading to less ad exposure. The latter might not be enough politically correct to have as a default browser feature? On Mar 4, 11:08 pm, Mike Beltzner beltz...@mozilla.com wrote: On 4-Mar-09, at 4:38 PM, Evan Martin wrote: Here's the core of that implementation: http://lab.arc90.com/experiments/readability/js/readability-0.1.js It's heuristic-based, e.g.: // Study all the paragraphs and find the chunk that has the most p's and keep it: For what it's worth, there are several reports on LifeHacker that the selected heuristic doesn't end up working for a lot of pages, but it's a clever start, to be sure. I continue to feel that this is a huge use case for browsers and something like this could be a major boon if the UI was right. Agreed. I think you'd need clearer controls about how to get back to the full page, and probably a smooth transition from full page to selected bit that uses visual momentum to keep the user's context. Something similar to how the lightboxes on many websites use now, but perhaps without the 3-d effect. Also, it might be powerful to let the user indicate the aspect of the page they want to focus on. 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: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
I just verified that this patch completely broke everything. You
committed late at night when no sheriff or anyone was around, and then
you went to bed.
Thanks for not testing your code, and not watching the tree go red after it.
Appreciation from another time zone,
-- dean
On Thu, Mar 5, 2009 at 7:38 AM, hc...@chromium.org wrote:
Author: hc...@chromium.org
Date: Wed Mar 4 22:38:52 2009
New Revision: 10972
Log:
Highlights of changes:
1. Added entry to ResourceResponseHead so that it contains
either a base::PlatformFile (OS_WIN) or
base::FileDescriptor (OS_POSIX) for passing the file
handle from browser to renderer process.
2. Also added IPC messages for reporting download progress
and ACK message for it. ResourceLoaderBridge::Peer::OnDownloadProgress
is added so that the peer is notified of the download
progress in the renderer process.
3. Load flag to kick start the resource loading for media
files. LOAD_MEDIA_RESOURCE is added so that
ResourceDispatcherHost knows how to use a different
ResourceHandler for handling media resource request.
Review URL: http://codereview.chromium.org/27168
Modified:
trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
trunk/src/chrome/browser/renderer_host/resource_handler.h
trunk/src/chrome/common/render_messages.h
trunk/src/chrome/common/render_messages_internal.h
trunk/src/chrome/common/resource_dispatcher.cc
trunk/src/chrome/common/resource_dispatcher.h
trunk/src/net/base/load_flags.h
trunk/src/net/http/http_cache.cc
trunk/src/net/http/http_cache_unittest.cc
trunk/src/net/url_request/url_request.h
trunk/src/webkit/glue/resource_loader_bridge.h
Modified: trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
==
--- trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
(original)
+++ trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc Wed
Mar 4 22:38:52 2009
@@ -815,6 +815,15 @@
response-response_head.content_length = request-GetExpectedContentSize();
request-GetMimeType(response-response_head.mime_type);
+ // Structure of ResourceResponseHead depends on the platform, so we do it
+ // differently.
+#if defined(OS_POSIX)
+ response-response_head.response_data_file.fd =
request-response_data_file();
+ response-response_head.response_data_file.auto_close = false;
+#elif defined(OS_WIN)
+ response-response_head.response_data_file = request-response_data_file();
+#endif
+
if (request-ssl_info().cert) {
int cert_id =
CertStore::GetSharedInstance()-StoreCert(
Modified: trunk/src/chrome/browser/renderer_host/resource_handler.h
==
--- trunk/src/chrome/browser/renderer_host/resource_handler.h (original)
+++ trunk/src/chrome/browser/renderer_host/resource_handler.h Wed Mar 4
22:38:52 2009
@@ -12,6 +12,11 @@
#ifndef CHROME_BROWSER_RENDERER_HOST_RESOURCE_HANDLER_H_
#define CHROME_BROWSER_RENDERER_HOST_RESOURCE_HANDLER_H_
+#include build/build_config.h
+#if defined(OS_POSIX)
+#include base/file_descriptor_posix.h
+#endif
+#include base/platform_file.h
#include chrome/common/filter_policy.h
#include net/url_request/url_request_status.h
#include webkit/glue/resource_loader_bridge.h
@@ -29,6 +34,20 @@
// Specifies if the resource should be filtered before being displayed
// (insecure resources can be filtered to keep the page secure).
FilterPolicy::Type filter_policy;
+
+ // A platform specific handle for a file that carries response data. This
+ // entry is used if the resource request is of type ResourceType::MEDIA and
+ // the underlying cache layer keeps the response data in a standalone file.
+#if defined(OS_POSIX)
+ // If the response data file is available, the file handle is stored in
+ // response_data_file.fd, its value is base::kInvalidPlatformFileValue
+ // otherwise.
+ base::FileDescriptor response_data_file;
+#elif defined(OS_WIN)
+ // An asynchronous file handle to the response data file, its value is
+ // base::kInvalidPlatformFileValue if the file is not available.
+ base::PlatformFile response_data_file;
+#endif
};
// Parameters for a synchronous resource response.
Modified: trunk/src/chrome/common/render_messages.h
==
--- trunk/src/chrome/common/render_messages.h (original)
+++ trunk/src/chrome/common/render_messages.h Wed Mar 4 22:38:52 2009
@@ -377,6 +377,9 @@
case ResourceType::OBJECT:
type = LOBJECT;
break;
+ case ResourceType::MEDIA:
+ type = LMEDIA;
+ break;
default:
type = LUNKNOWN;
break;
@@ -1334,12 +1337,14 @@
ParamTraitswebkit_glue::ResourceLoaderBridge::ResponseInfo::Write(m, p);
WriteParam(m,
[chromium-dev] Re: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
I didn't mean that to be such a personal flame, we need to have some
better guards to prevent this from happening. It's just frustrating
when the tree is broken for hours at a time. It's happened a lot
lately, the tree has been closed and/or hosed for the majority of my
workday week. The sheriff wakes up, reverts everything closes the
tree, nurses it back to heath, and then it happens again the next
morning. It's not really a good strategy.
Maybe we need to limit the hours people are commit, if a sheriff isn't
around to fix things? I don't really think that's a good strategy
either. I don't know.
On Thu, Mar 5, 2009 at 5:34 PM, Dean McNamee de...@chromium.org wrote:
I just verified that this patch completely broke everything. You
committed late at night when no sheriff or anyone was around, and then
you went to bed.
Thanks for not testing your code, and not watching the tree go red after it.
Appreciation from another time zone,
-- dean
On Thu, Mar 5, 2009 at 7:38 AM, hc...@chromium.org wrote:
Author: hc...@chromium.org
Date: Wed Mar 4 22:38:52 2009
New Revision: 10972
Log:
Highlights of changes:
1. Added entry to ResourceResponseHead so that it contains
either a base::PlatformFile (OS_WIN) or
base::FileDescriptor (OS_POSIX) for passing the file
handle from browser to renderer process.
2. Also added IPC messages for reporting download progress
and ACK message for it. ResourceLoaderBridge::Peer::OnDownloadProgress
is added so that the peer is notified of the download
progress in the renderer process.
3. Load flag to kick start the resource loading for media
files. LOAD_MEDIA_RESOURCE is added so that
ResourceDispatcherHost knows how to use a different
ResourceHandler for handling media resource request.
Review URL: http://codereview.chromium.org/27168
Modified:
trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
trunk/src/chrome/browser/renderer_host/resource_handler.h
trunk/src/chrome/common/render_messages.h
trunk/src/chrome/common/render_messages_internal.h
trunk/src/chrome/common/resource_dispatcher.cc
trunk/src/chrome/common/resource_dispatcher.h
trunk/src/net/base/load_flags.h
trunk/src/net/http/http_cache.cc
trunk/src/net/http/http_cache_unittest.cc
trunk/src/net/url_request/url_request.h
trunk/src/webkit/glue/resource_loader_bridge.h
Modified: trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
==
--- trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
(original)
+++ trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc Wed
Mar 4 22:38:52 2009
@@ -815,6 +815,15 @@
response-response_head.content_length = request-GetExpectedContentSize();
request-GetMimeType(response-response_head.mime_type);
+ // Structure of ResourceResponseHead depends on the platform, so we do it
+ // differently.
+#if defined(OS_POSIX)
+ response-response_head.response_data_file.fd =
request-response_data_file();
+ response-response_head.response_data_file.auto_close = false;
+#elif defined(OS_WIN)
+ response-response_head.response_data_file =
request-response_data_file();
+#endif
+
if (request-ssl_info().cert) {
int cert_id =
CertStore::GetSharedInstance()-StoreCert(
Modified: trunk/src/chrome/browser/renderer_host/resource_handler.h
==
--- trunk/src/chrome/browser/renderer_host/resource_handler.h (original)
+++ trunk/src/chrome/browser/renderer_host/resource_handler.h Wed Mar 4
22:38:52 2009
@@ -12,6 +12,11 @@
#ifndef CHROME_BROWSER_RENDERER_HOST_RESOURCE_HANDLER_H_
#define CHROME_BROWSER_RENDERER_HOST_RESOURCE_HANDLER_H_
+#include build/build_config.h
+#if defined(OS_POSIX)
+#include base/file_descriptor_posix.h
+#endif
+#include base/platform_file.h
#include chrome/common/filter_policy.h
#include net/url_request/url_request_status.h
#include webkit/glue/resource_loader_bridge.h
@@ -29,6 +34,20 @@
// Specifies if the resource should be filtered before being displayed
// (insecure resources can be filtered to keep the page secure).
FilterPolicy::Type filter_policy;
+
+ // A platform specific handle for a file that carries response data. This
+ // entry is used if the resource request is of type ResourceType::MEDIA
and
+ // the underlying cache layer keeps the response data in a standalone
file.
+#if defined(OS_POSIX)
+ // If the response data file is available, the file handle is stored in
+ // response_data_file.fd, its value is base::kInvalidPlatformFileValue
+ // otherwise.
+ base::FileDescriptor response_data_file;
+#elif defined(OS_WIN)
+ // An asynchronous file handle to the response data file, its value is
+ // base::kInvalidPlatformFileValue if the file is not available.
+ base::PlatformFile
[chromium-dev] Re: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
There is one thing though, I don't think hclam checkin turned any Linux tests red. The linux build was unusable, but the unit tests and layout tests were passing. It seems like there is a lack of tests here. When I woke up I reverted his change because it broke Purify on windows and another unit test on windows, on only 1 bot. There is a possibility that he did wait, but did not judge that the tree was red enough to worry about it. (the unit test did look like a flakyness, and Purify is often slow to give results). I learned just after the revert that it did fix the problem with linux. So, my recommendations: 1. hclam: don't resubmit until you are sure it does not break linux. I'm sure any linux people here can help you with this. 2. linux people: We need more tests. 3. Everyone: If the tree is broken, and no sheriff is around, please, try to find what broke it, and revert the change. If the tree is broken because of a problem with the buildbots, and no one is around to fix it, you can also page me. (I'll add the email alias to my who page). Nicolas On Thu, Mar 5, 2009 at 8:47 AM, Amanda Walker ama...@chromium.org wrote: On Thu, Mar 5, 2009 at 11:41 AM, Dean McNamee de...@chromium.org wrote: Maybe we need to limit the hours people are commit, if a sheriff isn't around to fix things? I don't really think that's a good strategy either. I don't know. Well, it's not the sheriff's responsibility to fix every checkin, they're just there as a safety net. All of us should be making sure we don't break the build, every time we commit something. I don't think limiting commit hours is a workable strategy, given how many people are working across so many time zones. However, last night was a good reminder that no one should ever commit and then leave without watching the build to make sure it landed cleanly. It just leaves a mess for other people, which is unfriendly. --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: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
On Thu, Mar 5, 2009 at 6:01 PM, Nicolas Sylvain nsylv...@chromium.org wrote: There is one thing though, I don't think hclam checkin turned any Linux tests red. The linux build was unusable, but the unit tests and layout tests were passing. It seems like there is a lack of tests here. Yeah, we aren't running UI tests yet, and that would have caught this (or page cycler or anything else). I think we're getting close, but there is a bunch of things involved to get everything working. We definitely need better testing, but I think we're all test burnt out from working on layout tests, and just want to get some of our UI going. When I woke up I reverted his change because it broke Purify on windows and another unit test on windows, on only 1 bot. There is a possibility that he did wait, but did not judge that the tree was red enough to worry about it. (the unit test did look like a flakyness, and Purify is often slow to give results). I learned just after the revert that it did fix the problem with linux. So, my recommendations: 1. hclam: don't resubmit until you are sure it does not break linux. I'm sure any linux people here can help you with this. 2. linux people: We need more tests. 3. Everyone: If the tree is broken, and no sheriff is around, please, try to find what broke it, and revert the change. I pretty much wasted my day doing 3). It was my fault for not starting at the top and just going down, reverting, rebuild, etc. That would have found it pretty quickly. Mostly because it takes so long to build, I instead tried to debug it, hoping I would find the answer quickly. In the end I chased a bunch of wrong ideas and wasted a ton of time on it. If the tree is broken because of a problem with the buildbots, and no one is around to fix it, you can also page me. (I'll add the email alias to my who page). It's not so fair to wake you up in the middle of the night. I'd rather just take the day off :) I'm sure I was far too hard on hclam, I'm not super angry or anything. I am just trying to point out a problem that we continually seem to have, and we obviously need to improve here and have clear steps about how we're doing it. More tests on Mac and Linux definitely need to happen. If SVN wasn't so slow, I would have just sync'd back a few revisions. We should make our build and source control faster, the build I know we're working on. I think also some improvement to the waterfall is going to be really helpful. We have so many builds and builders and tests now, it's really hard to take all the information in. When there is a problem, we should have like a top 10 recent shady commits page, which tries to attribute new failures across all our builders and tests to a change list. It's often hard to tell from a single builder if a patch was bad, but if it caused a purify problem here, another problem here, etc, then at least that would give people a good starting point of where to look when they think the tree has gone sour. We also obviously need to improve our test flakiness. I've committed more than my share of shady patches, and I think so has the rest of the team. Again, I didn't meant to try to blame things so personally. And you're right, even when you do commit and watch the tree, it's often hard to tell the outcome, when it goes from kinda red to still kinda red, that isn't a great gauge. It just seems with all of the new platforms / code / complexity, we need some better ways of managing when it happens, because it's going to keep on happening. I think the outcome goal should be to not have sheriffs, and to have a system that can handle itself. Nicolas On Thu, Mar 5, 2009 at 8:47 AM, Amanda Walker ama...@chromium.org wrote: On Thu, Mar 5, 2009 at 11:41 AM, Dean McNamee de...@chromium.org wrote: Maybe we need to limit the hours people are commit, if a sheriff isn't around to fix things? I don't really think that's a good strategy either. I don't know. Well, it's not the sheriff's responsibility to fix every checkin, they're just there as a safety net. All of us should be making sure we don't break the build, every time we commit something. I don't think limiting commit hours is a workable strategy, given how many people are working across so many time zones. However, last night was a good reminder that no one should ever commit and then leave without watching the build to make sure it landed cleanly. It just leaves a mess for other people, which is unfriendly. --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: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
On Thu, Mar 5, 2009 at 12:38 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote: everytime I do a checkin I do a sync and send it to the try server, which really takes me a lot of time, but still try server is showing me green light to check in, am I suppose to not trust the try server and rely on human intelligence? In this case watching the build wouldn't have helped, since the buildbots stayed green (I had misinterpreted Dean's original message, the tone of which he has since apologized for). However, to answer the general question, you should not completely trust the try server. If the try server breaks, it's a very good indication that an actual commit would break, but the reverse is not true. If the try server succeeds, it doesn't mean that a commit will succeed, since the try server runs fewer tests (and there may be commits to the tree in between doing a try and doing a commit). So even if the try succeeds, it's still important to watch the buildbots to make sure the actual commit also succeeds. That wasn't the problem in this instance (you wouldn't have seen this failure), but I wanted to make sure people don't rely too much on the try server. It's a good preflight check, but it won't catch everything. --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: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
On Thu, Mar 5, 2009 at 7:03 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote: 2009/3/5 Amanda Walker ama...@chromium.org On Thu, Mar 5, 2009 at 12:38 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote: everytime I do a checkin I do a sync and send it to the try server, which really takes me a lot of time, but still try server is showing me green light to check in, am I suppose to not trust the try server and rely on human intelligence? In this case watching the build wouldn't have helped, since the buildbots stayed green (I had misinterpreted Dean's original message, the tone of which he has since apologized for). However, to answer the general question, you should not completely trust the try server. If the try server breaks, it's a very good indication that an actual commit would break, but the reverse is not true. If the try server succeeds, it doesn't mean that a commit will succeed, since the try server runs fewer tests (and there may be commits to the tree in between doing a try and doing a commit). So even if the try succeeds, it's still important to watch the buildbots to make sure the actual commit also succeeds. That wasn't the problem in this instance (you wouldn't have seen this failure), but I wanted to make sure people don't rely too much on the try server. It's a good preflight check, but it won't catch everything. Thanks Amanda and Nicolas for the clarifactions. Sorry Dean for wasting your time to debug, I should have comminucated better as the patch really is posix specific. Sorry all chromium commiters if I have caused trouble to you. Hey, it's no big deal. I just want to make sure we took the instance as an example of how we can improve our build setup, and how we can keep the tree more stable. Alpha --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: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
I looked at yesterday Alpha's try run on linux, the try server runs ui tests and it was green. The mac try slave were dead last evening. I would only blame poor testing on linux side. I'm adding ui testprinting tests on modules mac linux on next master restart. And oh, please read the 3 lines manual at http://build.chromium.org/buildbot/try-server Thanks, M-A On Thu, Mar 5, 2009 at 1:05 PM, Dean McNamee de...@chromium.org wrote: On Thu, Mar 5, 2009 at 7:03 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote: 2009/3/5 Amanda Walker ama...@chromium.org On Thu, Mar 5, 2009 at 12:38 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote: everytime I do a checkin I do a sync and send it to the try server, which really takes me a lot of time, but still try server is showing me green light to check in, am I suppose to not trust the try server and rely on human intelligence? In this case watching the build wouldn't have helped, since the buildbots stayed green (I had misinterpreted Dean's original message, the tone of which he has since apologized for). However, to answer the general question, you should not completely trust the try server. If the try server breaks, it's a very good indication that an actual commit would break, but the reverse is not true. If the try server succeeds, it doesn't mean that a commit will succeed, since the try server runs fewer tests (and there may be commits to the tree in between doing a try and doing a commit). So even if the try succeeds, it's still important to watch the buildbots to make sure the actual commit also succeeds. That wasn't the problem in this instance (you wouldn't have seen this failure), but I wanted to make sure people don't rely too much on the try server. It's a good preflight check, but it won't catch everything. Thanks Amanda and Nicolas for the clarifactions. Sorry Dean for wasting your time to debug, I should have comminucated better as the patch really is posix specific. Sorry all chromium commiters if I have caused trouble to you. Hey, it's no big deal. I just want to make sure we took the instance as an example of how we can improve our build setup, and how we can keep the tree more stable. Alpha --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: Visual Studio chrome solution /Plugin development / does not build a .lib for dlls
About 2: I was just faced with the same problem in another project on my job. And it turned out that Visual Studio doesn't create *.lib file if there's no functions declared with __declspec(dllexport) or mentioned in *.def file in the project. Nothing to export from dll - no *.lib required. ;-) You can check if this is the case for you with depends.exe. Pavel On Thu, Mar 5, 2009 at 4:07 PM, eager_learner vijay.sankar.ra...@gmail.com wrote: Hello folks building Chrome on Visual Studio 2008 or 2005. I have been trying to integrate a third-party library into chrome to develop and test a plugin. Just like all plugins, this will be built as a dll which should summoned for designated content-type. I have read in many postings that the NPAPI like external API to develop plugins will be available in May so I decided to get on with work and implement this as an internal plugin by hacking my way through plugin_list.cc and the Glue.vcproject. When I navigate to my test site with content-type, the plugin does get invoked. However all this code is added to the glue.vcproject. I have the code for the thirdparty library that I made a dll project. Here is where the problem starts 1. Glue.vcproject builds a static library (.lib) which calls functions from my third-party project which is built as a DLL. Is this plain wrong? Can a static library make calls to a dynamic library? 2. I was able to build Glue.vcproject when I added my third-party project as project dependency to Glue.vcproject. However, chrome_dll which links to Glue.lib did not link complaining about unresolved references. It was looking for my project.lib. But magically, my project.vcproj only builds the dll no accompanying .lib. I have tried turning on and off various vcProject options... In the build output, I clearly see /DYNAMICBASE:NO /FIXED:No /IMPLIB being used. I am clueless and would like to know and can share my windows messenger id so that someone can take a look at the vcproject to find out what could be going wrong. Sincerely --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Accesskeys on the Mac
The definition of what the accesskey modifier is the result of
EventHandler::accessKeyModifiers(). On Windows it's
althttp://trac.webkit.org/browser/trunk/WebCore/page/win/EventHandlerWin.cpp,
and on Chromium it's also
althttp://trac.webkit.org/browser/trunk/WebCore/page/chromium/EventHandlerChromium.cpp
.
The question is: What to make it on the Mac? And how to do it right?
Mozilla apparently switched recently to use the command key. They used to
use the control key. What does Safari use? Much more difficult question. The
codehttp://trac.webkit.org/browser/trunk/WebCore/page/mac/EventHandlerMac.mmsays:
unsigned EventHandler::accessKeyModifiers()
{
// Control+Option key combinations are usually unused on Mac OS X, but
not when VoiceOver is enabled.
// So, we use Control in this case, even though it conflicts with
Emacs-style key bindings.
// See https://bugs.webkit.org/show_bug.cgi?id=21107 for more
detail.
if (AXObjectCache::accessibilityEnhancedUserInterfaceEnabled())
return PlatformKeyboardEvent::CtrlKey;
return PlatformKeyboardEvent::CtrlKey | PlatformKeyboardEvent::AltKey;
}
And if you go to the layout test, you'll see that on the Mac it uses the
modifiers ctrl+alt. This solution is problematic for two reasons.
The first is that using a dual modifier sucks. It makes it extremely
difficult to use accesskeys.
The second is that triggering them with a single modifier (just the ctrl
key) on my machine works fine in Safari. Which puts me in a quandary,
because I'm not sure how Safari's doing that (I'm digging now). If we alter
our accessKeyModifiers() to return the dual modifier, layout tests start
passing, but it's hard to use. If we use just ctrl, then it's easy to use
but we fail tests. And somehow Safari does both...
Avi
--~--~-~--~~~---~--~~
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: Accesskeys on the Mac
It sounds like they only use the single modifier when the
accessibility system setting is turned on, otherwise they use the dual
one. Why don't we just do the same thing? I'm pretty sure we should
match the platform default browser instead of emacs.
-Ben
On Thu, Mar 5, 2009 at 1:22 PM, Avi Drissman a...@google.com wrote:
The definition of what the accesskey modifier is the result of
EventHandler::accessKeyModifiers(). On Windows it's alt, and on Chromium
it's also alt.
The question is: What to make it on the Mac? And how to do it right?
Mozilla apparently switched recently to use the command key. They used to
use the control key. What does Safari use? Much more difficult question. The
code says:
unsigned EventHandler::accessKeyModifiers()
{
// Control+Option key combinations are usually unused on Mac OS X, but
not when VoiceOver is enabled.
// So, we use Control in this case, even though it conflicts with
Emacs-style key bindings.
// See https://bugs.webkit.org/show_bug.cgi?id=21107 for more
detail.
if (AXObjectCache::accessibilityEnhancedUserInterfaceEnabled())
return PlatformKeyboardEvent::CtrlKey;
return PlatformKeyboardEvent::CtrlKey | PlatformKeyboardEvent::AltKey;
}
And if you go to the layout test, you'll see that on the Mac it uses the
modifiers ctrl+alt. This solution is problematic for two reasons.
The first is that using a dual modifier sucks. It makes it extremely
difficult to use accesskeys.
The second is that triggering them with a single modifier (just the ctrl
key) on my machine works fine in Safari. Which puts me in a quandary,
because I'm not sure how Safari's doing that (I'm digging now). If we alter
our accessKeyModifiers() to return the dual modifier, layout tests start
passing, but it's hard to use. If we use just ctrl, then it's easy to use
but we fail tests. And somehow Safari does both...
Avi
--~--~-~--~~~---~--~~
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: Accesskeys on the Mac
And when I build WebKit and run it in Safari, only ctrl+alt work. Weird. I'm
doing testing now to see what this fixes.
Avi
On Thu, Mar 5, 2009 at 4:38 PM, Avi Drissman a...@google.com wrote:
That value gets set in WebKit's WebFrame.mm:
if ([[NSApp
accessibilityAttributeValue:NSAccessibilityEnhancedUserInterfaceAttribute]
boolValue])
AXObjectCache::*enableEnhancedUserInterfaceAccessibility*();
What is that mysterious NSAccessibilityEnhancedUserInterfaceAttribute? It's
a secret AppKit value, equaling @AXEnhancedUserInterface. What's *that*?
Oh, it's a magical value set by VoiceOver as a hint to certain internal
AppKit controls to alter their behavior slightly to make life better for it.
(See
http://lists.apple.com/archives/accessibility-dev/2006/Feb/msg9.html).
That message is the only documentation past seeing it in WebKit archives.
I'm fine with this, but I just want to know how I can do both...
Avi
On Thu, Mar 5, 2009 at 4:34 PM, Thomas Van Lenten
thoma...@chromium.orgwrote:
Does the universal access setting w/in safari's prefs change this in any
way?
TVL
On Thu, Mar 5, 2009 at 4:30 PM, Avi Drissman a...@google.com wrote:
I'm trying to figure out the exact meaning of
accessibilityEnhancedUserInterfaceEnabled because I'm getting that effect on
my Mac without any accessibility. In addition, what I forgot to mention is
that *both* ctrl *and* ctrl+alt work in Safari for me, while we can only
pick one to return from accessKeyModifiers() and whichever one we don't
return doesn't work.
Avi
On Thu, Mar 5, 2009 at 4:24 PM, Ben Goodger (Google)
b...@chromium.orgwrote:
It sounds like they only use the single modifier when the
accessibility system setting is turned on, otherwise they use the dual
one. Why don't we just do the same thing? I'm pretty sure we should
match the platform default browser instead of emacs.
-Ben
On Thu, Mar 5, 2009 at 1:22 PM, Avi Drissman a...@google.com wrote:
The definition of what the accesskey modifier is the result of
EventHandler::accessKeyModifiers(). On Windows it's alt, and on
Chromium
it's also alt.
The question is: What to make it on the Mac? And how to do it right?
Mozilla apparently switched recently to use the command key. They used
to
use the control key. What does Safari use? Much more difficult
question. The
code says:
unsigned EventHandler::accessKeyModifiers()
{
// Control+Option key combinations are usually unused on Mac OS
X, but
not when VoiceOver is enabled.
// So, we use Control in this case, even though it conflicts with
Emacs-style key bindings.
// See https://bugs.webkit.org/show_bug.cgi?id=21107 for more
detail.
if (AXObjectCache::accessibilityEnhancedUserInterfaceEnabled())
return PlatformKeyboardEvent::CtrlKey;
return PlatformKeyboardEvent::CtrlKey |
PlatformKeyboardEvent::AltKey;
}
And if you go to the layout test, you'll see that on the Mac it uses
the
modifiers ctrl+alt. This solution is problematic for two reasons.
The first is that using a dual modifier sucks. It makes it extremely
difficult to use accesskeys.
The second is that triggering them with a single modifier (just the
ctrl
key) on my machine works fine in Safari. Which puts me in a quandary,
because I'm not sure how Safari's doing that (I'm digging now). If we
alter
our accessKeyModifiers() to return the dual modifier, layout tests
start
passing, but it's hard to use. If we use just ctrl, then it's easy to
use
but we fail tests. And somehow Safari does both...
Avi
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Mergers: ignore InspectorController changes for a little while.
If you don't do the merges, you can stop reading now -- though you might ask yourself why you're not doing the merges. They are so much fun. In the next few days (hopefully not weeks), I am making changes to InspectorController in an effort to unfork it. This is the good news. The bad news is that there's a certain transition period, during which merging InspectorController will seem a little bit ... difficult. So, to make your merging work easier, here are the instructions: * Don't accept any changes from upstream to InspectorController.(cpp|h|idl). See? Easy! :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] More plugin questions
Hello Plugin Gurus The following link is very well written and I hope it still holds good http://sites.google.com/a/chromium.org/dev/developers/design-documents/plugin-architecture I have some followup questions on plugin development (internal) 1. Based on the plugin architecture design document, can you point me to an existing plugin (flash, shockwave, activeX) code file names? The source Navigator project that I have created does not show any inheritance of WebPplugin 2. Again the debugging process seems a little difficult if new processes are spawned (one for the browser, one for the renderer and one for the plugin). How can we attach Visual Studio to the plugin? 3. Do plugin writers need to know anything about the class PluginInstance? It seems to create the WebPlugin or atleast gets passed it and has a reference to it. Simply put, what needs to be done by plugin developers to develop an internal plugin? Does the NPAPI need to know about the PluginInstance? Perhaps there is a clearer document that explains this. Thanks Vijay --~--~-~--~~~---~--~~ 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: Profile Corruption, cause?
Mohamed, I'm glad to see your interest in tackling this problem. Unfortunately, that data is collected under an agreement between the user and Google, so we cannot share the dumps. It's OK to share the stack traces, which have no personally identifying information, but I'm not sure we can even find a set of reports definitely correlated with profile corruption. This makes me wonder if we should have an integrity check when we detect that the browser crashed in the previous session. It might be useful to offer to reset the user's profile or (ideally) drop the parts that are corrupt. I'd personally rather drop my entire browsing history to keep my saved passwords (and vice versa). The UI would have to be diplomatic. Maybe some developers who have dealt with corruption issues in the past can provide some advice on things we could do to address corruption. Thanks, Mark On Thu, Mar 5, 2009 at 21:09, Mohamed Mansour m0.interact...@gmail.comwrote: Hello, on the Google Help Forums, 80-85% of the crashes reported there are due to profile corruptions. What they have to do is run chrome in a new user directory, chrome.exe --user-data-dir=c:\foo, or deleting the local state file. Anyone have any idea what may of caused this? Users who don't know the answer to this problem, usually give up using the browser. Chrome is a great browser, and its sad to see people not using it because of this. If anyone has any crash logs due to this (from user reporting), and since its internal to Google, can you share the stack trace? I would like to spend one weekend taking a look at it. Thanks! --~--~-~--~~~---~--~~ 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: Profile Corruption, cause?
I suspect this is like crashes due to memory corruption: It won't do much good to stare at the call stack at the time corruption was detected; we need to know the stack at the time corruption occurred (assuming this is Chrome that is corrupting the profile). For memory corruptions we have gflags; I wonder if there is something in SqlLite that can help us here? On Thu, Mar 5, 2009 at 22:20, Mark Larson (Google) m...@chromium.org wrote: Mohamed, I'm glad to see your interest in tackling this problem. Unfortunately, that data is collected under an agreement between the user and Google, so we cannot share the dumps. It's OK to share the stack traces, which have no personally identifying information, but I'm not sure we can even find a set of reports definitely correlated with profile corruption. This makes me wonder if we should have an integrity check when we detect that the browser crashed in the previous session. It might be useful to offer to reset the user's profile or (ideally) drop the parts that are corrupt. I'd personally rather drop my entire browsing history to keep my saved passwords (and vice versa). The UI would have to be diplomatic. Maybe some developers who have dealt with corruption issues in the past can provide some advice on things we could do to address corruption. Thanks, Mark On Thu, Mar 5, 2009 at 21:09, Mohamed Mansour m0.interact...@gmail.comwrote: Hello, on the Google Help Forums, 80-85% of the crashes reported there are due to profile corruptions. What they have to do is run chrome in a new user directory, chrome.exe --user-data-dir=c:\foo, or deleting the local state file. Anyone have any idea what may of caused this? Users who don't know the answer to this problem, usually give up using the browser. Chrome is a great browser, and its sad to see people not using it because of this. If anyone has any crash logs due to this (from user reporting), and since its internal to Google, can you share the stack trace? I would like to spend one weekend taking a look at it. Thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
