headers
Peter Kasting | 1 Nov 2011 03:41
Picon
Favicon

Re: Presubmit checks taking a long time on cygwin

On Fri, Oct 28, 2011 at 6:45 PM, Dirk Pranke <dpranke <at> chromium.org> wrote:
I am following up w/ Peter off-list. Will report back if we find
anything of general interest.

Update: the slowdown seemed to have been caused by upgrading my cygwin svn (which I use in preference to the depot_tools svn) to 1.6.17 or something like that.  I just upgraded svn again, to 1.7.1, and the problem appears to be much reduced (I haven't tested extensively so I can't say whether it's completely back to its previous level.

For anyone who uses cygwin svn, this may be useful info.  Note, however, that svn 1.7 uses a different metadata format on the client, and will require running "svn upgrade" manually on all checkouts before using them.  There are no client<->server version incompatibilities, so you can do this safely, but it's a time-consuming step -- updating one complete WebKit checkout + complete chrome checkout took over an hour.

PK

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 0 comments |
headers
Prasad Tammana | 1 Nov 2011 03:59

Giving focus to the root window of the screen on Linux

Is there a way for an app to give focus to the root window on Linux? The only I found looking around is to set user time on the root window to be current and that's not working for me. Here is what I'm doing:


    GdkWindow* root_window = gdk_screen_get_root_window(gdk_screen_get_default());
    gdk_x11_window_set_user_time(root_window, GDK_CURRENT_TIME);

I tried a few variations of this without luck. I also tried the following and that didn't work either:

    GdkWindow* root_window = gdk_screen_get_root_window(
        gdk_screen_get_default());
    gdk_window_focus(root_window, GDK_CURRENT_TIME);


In the scenario where the only browser windows are panels, and all the panels are minimized, I'd like for Chrome to give up focus and they way I'm trying to do it is by giving focus to the root window. Is there a more direct way for an app to give up focus?

Thanks,
Prasad

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 4 comments |
headers
Brian Ryner | 1 Nov 2011 05:29

trying to debug a crash in WebNodeCollection

Hi,


In PhishingDOMFeatureExtractor, we loop through all of the documents in the WebView, and for each document, we use WebDocument::all() to get a WebNodeCollection containing all of the elements so that we can traverse them.  As I've mentioned previously, this class breaks up its work into chunks to avoid blocking the UI thread for too long.  When we post a task to continue processing later, the WebNodeCollection is saved and reused when the continuation task runs.

I'm seeing a small number of crashes in M15 that look like they're caused by a WebNodeCollection having some kind of stale pointer internally.  Here's an example (from http://crash/reportdetail?reportid=af29fba830a0e3c4) :

Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_READ <at> 0x051a5d24 )

0x026c80be [chrome.dll - htmlcollection.cpp:126] WebCore::HTMLCollection::itemAfter(WebCore::Element *)
0x026c839a [chrome.dll - htmlcollection.cpp:256] WebCore::HTMLCollection::nextItem()
0x01cd3c02 [chrome.dll - webnodecollection.cpp:77] WebKit::WebNodeCollection::nextItem()
0x01e94aa3 [chrome.dll - phishing_dom_feature_extractor.cc:229] safe_browsing::PhishingDOMFeatureExtractor::ExtractFeaturesWithTimeout()
0x023c7828 [chrome.dll - task.h:164] ScopedRunnableMethodFactory<safe_browsing::PhishingClassifier>::RunnableMethod<void ( safe_browsing::PhishingClassifier::*)(void),Tuple0>::Run()
0x01e395ed [chrome.dll - task.cc:56] base::subtle::TaskClosureAdapter::Run()
0x01e2ae65 [chrome.dll - message_loop.cc:476] MessageLoop::RunTask(MessageLoop::PendingTask const &)

The crashing code in HTMLCollection is:

    Node* current;
    if (!previous)
        current = m_base->firstChild();
    else
        current = nextNodeOrSibling(m_base.get(), previous, deep);

    for (; current; current = nextNodeOrSibling(m_base.get(), current, deep)) {
        if (!current->isElementNode())   <-- line 126
            continue;

I've poked around the code a bit and can't find anything that's obviously wrong.  As I understand it, WebNodeCollection / HTMLCollection is supposed to handle invalidating itself if the element it's pointing to has been removed from the document.  Does anyone have any suggestions for what might be causing this crash?

Thanks,

--
-Brian

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 0 comments |
headers
Dmitry Lomov | 1 Nov 2011 06:57

Antialiasing turns off in edit fields on MacOS X in stable Chrome 15?

Hi folks,

after I got stable Chrome M15 on my MacBook Air, I occasionally see anti-aliasing turning off once I start editing in text area (such as GMail mail editor).

This happens occasionally (but quite often to annoy), and it looks like the more complex the text I edit the more likely it is to happen.
Is it known? Should I try to repro it more reliably?

Thanks!
Mitya

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 2 comments |
headers
Vangelis Kokkevis | 1 Nov 2011 07:12
Picon
Favicon

Re: Antialiasing turns off in edit fields on MacOS X in stable Chrome 15?

Have you by any chance enabled "Gpu compositing for all pages" in about:flags ? See:




Vangelis


On Mon, Oct 31, 2011 at 10:57 PM, Dmitry Lomov <dslomov <at> chromium.org> wrote:
Hi folks,
after I got stable Chrome M15 on my MacBook Air, I occasionally see anti-aliasing turning off once I start editing in text area (such as GMail mail editor).

This happens occasionally (but quite often to annoy), and it looks like the more complex the text I edit the more likely it is to happen.
Is it known? Should I try to repro it more reliably?

Thanks!
Mitya

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 1 comment |
headers
Dmitry Lomov | 1 Nov 2011 09:55
Picon
Favicon

Re: Antialiasing turns off in edit fields on MacOS X in stable Chrome 15?

That was it - thank you!

On Mon, Oct 31, 2011 at 11:12 PM, Vangelis Kokkevis <vangelis <at> google.com> wrote:
Have you by any chance enabled "Gpu compositing for all pages" in about:flags ? See:



Vangelis


On Mon, Oct 31, 2011 at 10:57 PM, Dmitry Lomov <dslomov <at> chromium.org> wrote:
Hi folks,
after I got stable Chrome M15 on my MacBook Air, I occasionally see anti-aliasing turning off once I start editing in text area (such as GMail mail editor).

This happens occasionally (but quite often to annoy), and it looks like the more complex the text I edit the more likely it is to happen.
Is it known? Should I try to repro it more reliably?

Thanks!
Mitya

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev


--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 0 comments |
headers
John Abd-El-Malek | 1 Nov 2011 16:57

Re: TEST= field in the changelists

I think there isn't any new stuff in this email, so I feel like we're going in circles. Your email below describes a use case that you think is very important. However as I said in my previous email, this isn't why this tag got added. It was added for the test team. Our bugs should have information on how to repro a problem, and it seems that your use case below is attempting to add redundancy. If we're going to ensure anything, it should be that all of our bugs have repro instructions. There's no need to duplicate instructions.

On Mon, Oct 31, 2011 at 2:17 PM, Peter Kasting <pkasting <at> chromium.org> wrote:
On Mon, Oct 31, 2011 at 1:58 PM, John Abd-El-Malek <jam <at> chromium.org> wrote:
I think it's obvious that there are big disagreements here. The test team asked for this to be added long time ago. Since then, some people have used it for another meaning (message to other developers, and not to test team). Now people in the latter camp are wanting to force everyone to adopt their usage.

I think you're misunderstanding me, assuming you're claiming I'm in the second camp.

The TEST= field is for the test team.  It is also useful to anyone else who happens to want to test your change and doesn't have the context that the CL author and reviewer have.  It is not a "message to other developers" and in particular not a message to the reviewer (who maybe can figure out how to test the change anyway).

The principle behind my comments is as follows: When you write any change you should think about how it can be manually tested (generally by the test folks, conceivably by other interested parties).  Writing some non-empty TEST= field shows that you did so.  Doing it on every change keeps you in the (good) habit of thinking about it.  Having it present before checkin means your reviewer can double-check that you thought about it.  And having it on the checkin itself means that if a QA person looks at the change for whatever reason they'll know whether and how to test it.

By contrast, not adding the field conveys none of those benefits.  Writing "TEST=" alone is even worse as that looks to me (as someone reading the CL) as if you meant to write something but forgot to do so.

What I am really asking for in my reviews is not that people tell me how to test their change, but that they have thought about how some arbitrary person could test their change.  In that sense I believe I am upholding the spirit of TEST= as it was originally created.

PK

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 2 comments |
headers
Lambros Lambrou | 1 Nov 2011 18:32

Re: Giving focus to the root window of the screen on Linux

Quoted from here:

A convention is also required for clients that want to give up the input focus. There is no safe value set for them to set the input focus to; therefore, they should ignore input material.

Convention

Clients should not give up the input focus of their own volition. They should ignore input that they receive instead.

So, if we believe the ICCCM, then there's no simple way for an app to give up focus.  It has to ignore input instead.

Anyone else have any better ideas?
Lambros


On Mon, Oct 31, 2011 at 7:59 PM, Prasad Tammana <prasadt <at> chromium.org> wrote:
Is there a way for an app to give focus to the root window on Linux? The only I found looking around is to set user time on the root window to be current and that's not working for me. Here is what I'm doing:

    GdkWindow* root_window = gdk_screen_get_root_window(gdk_screen_get_default());
    gdk_x11_window_set_user_time(root_window, GDK_CURRENT_TIME);

I tried a few variations of this without luck. I also tried the following and that didn't work either:

    GdkWindow* root_window = gdk_screen_get_root_window(
        gdk_screen_get_default());
    gdk_window_focus(root_window, GDK_CURRENT_TIME);


In the scenario where the only browser windows are panels, and all the panels are minimized, I'd like for Chrome to give up focus and they way I'm trying to do it is by giving focus to the root window. Is there a more direct way for an app to give up focus?

Thanks,
Prasad

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 1 comment |
headers
Tony Chang | 1 Nov 2011 18:37

Re: Giving focus to the root window of the screen on Linux

On Mon, Oct 31, 2011 at 7:59 PM, Prasad Tammana <prasadt <at> chromium.org> wrote:
In the scenario where the only browser windows are panels, and all the panels are minimized, I'd like for Chrome to give up focus and they way I'm trying to do it is by giving focus to the root window. Is there a more direct way for an app to give up focus?

Doesn't the window manager automatically handle focus for you? That is, if the last chrome window is a panel and you call gtk_window_iconify() on it, the window manager should automatically shift focus to the previous app selected.

I suspect when you say, "all the panels are minimized", you mean that you're changing the appearance of the panels, but not actually calling gtk_window_iconify(). This is going to be hard to get right. If you look at the code for gdk_window_focus[1], you'll see that it sends _NET_ACTIVE_WINDOW to the window, but it's up to the window manager whether to honor that or not.  I suspect metactiy/compiz is ignoring the request because it doesn't make sense.

Also, I suspect this won't work correctly with focus follows mouse if the window is still under the mouse cursor after "minimizing".  The window will probably re-get focus as soon as you move your mouse.

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 1 comment |
headers
Peter Kasting | 1 Nov 2011 18:42

Re: TEST= field in the changelists

On Tue, Nov 1, 2011 at 8:57 AM, John Abd-El-Malek <jam <at> chromium.org> wrote:
I think there isn't any new stuff in this email, so I feel like we're going in circles.

OK.  Then in the interest of moving on with our lives, I propose that we leave the presubmit check and the Chromium docs as they are and leave usage of TEST= up to author and reviewer discretion.  (Sorry Dirk.)

PK

--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Permalink | Reply | 1 comment |

Gmane