Hi,
Is there any way to get know if InspectorDebuggerAgent::didPause call
was due to an exception or not? I have tried to use
scriptState-hadException() inside this function but it seems that the
hadException function always returns false.
Thanks,
Hi Tomasz,
There is no need to differentiate between pause due to an exception and due
to a breakpoint hit and there are no means to determine that in
InspectorDebuggerAgent::didPause. Detailed information about the break event
is available in
Hi Tomasz,
I have a patch for JavaScriptCore to let you determine if an exception happened
and what it was, if you're using JSC instead of V8.
We found that users of the front-end wanted to know if the pause was due to an
exception, and if so, what it was.
Jamey
On Oct 19, 2010, at 9:12 AM,
Hi Jamey,
Yes, I am using JSC.
I have a patch for JavaScriptCore to let you determine if an exception
happened and what it was, if you're using JSC instead of V8.
Could you provide this patch?
We found that users of the front-end wanted to know if the pause was due
to an exception, and if
Hi Tomasz,
I don't have time to update the Web Inspector UI to use this feature, but I'll
find the patch and upload it to bugs.webkit.org and CC you. We used it with our
frontend that adds Eclipse Chrome Dev Tools support with QtWebKit which
currently uses JSC rather than V8.
Jamey
On Oct
Put
* {
-webkit-user-select: none;
}
in your user-agent stylesheet?
Simon
On Oct 18, 2010, at 10:12 PM, Efan... wrote:
Hi
I am totally new to this group.
I want to disable selection of Text and graphics in my QWebView, it seems
that there is no way via Qt i can do this , so only
15.10.2010, в 07:39, Eric Seidel написал(а):
BTW, the commit-queue has started complaining publicly about flaky tests:
https://bugs.webkit.org/show_bug.cgi?id=47698#c5
Hopefully this will bring further awareness to the issue.
I find this extremely annoying and offensive. Half of my
That does not sound expected or desired. Could you point me to which
Chromium builders are responsible for so much data?
I suspect this is an artifact of new-run-webkit-tests or how the
Chromium builders are set up.
On Tue, Oct 19, 2010 at 9:12 AM, William Siegrist wsiegr...@apple.com wrote:
On Tue, Oct 19, 2010 at 9:20 AM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:
Ins't this due to the fact Chromium bots run pixel tests and others don't?
- Ryosuke
On Tue, Oct 19, 2010 at 9:17 AM, Eric Seidel e...@webkit.org wrote:
That does not sound expected or desired. Could you point me
Apparently DirectX SDK is now a required tool to get building on Windows. I
fought for 2 days with my build before stumbling across this old thread.
Are you still planning to add this to webkit.org/building/tools.html? Or,
tell me how and I'll update that page.
Thanks,
Jenn
On Tue, Nov 24,
If you do not own a build slave for build.webkit.org, you can stop reading.
If you maintain a buildbot slave for build.webkit.org, please make sure the
umask is set to 022. By default, the umask is 077 and this makes the results
only readable by the user that uploads them to the master. We
Submit a patch to modify this page:
http://trac.webkit.org/browser/trunk/WebKitSite/building/tools.html
- Ryosuke
On Tue, Oct 19, 2010 at 9:30 AM, Jenn Braithwaite (胡慧鋒) je...@google.comwrote:
Apparently DirectX SDK is now a required tool to get building on Windows.
I fought for 2 days with
I would venture to guess that's probably it.
:DG
On Tue, Oct 19, 2010 at 9:21 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Oct 19, 2010 at 9:20 AM, Ryosuke Niwa ryosuke.n...@gmail.com
wrote:
Ins't this due to the fact Chromium bots run pixel tests and others don't?
- Ryosuke
On Tue,
Linux, Mac, and Win Release Tests. Note the size of the ZIP files at the bottom
of these pages:
http://build.webkit.org/old-results/Chromium%20Linux%20Release%20%28Tests%29/
versus:
http://build.webkit.org/old-results/SnowLeopard%20Intel%20Leaks/
If it's useful data, I'll store it for you. I
It's that combined with the fact that Chromium runs some tests that are
expected to fail. As the number of tests chromium is failing and runs
shrinks, the storage growth will shrink as well.
Do we store results for tests that are marked WONTFIX? We probably
shouldn't. IMO we shouldn't even run
Hi All unfortunately I can not use JAVA script or any thing like that cause
my application is totally c++ , QT based.
I need to make the change in webkit src code I guess.
On Tue, Oct 19, 2010 at 8:39 AM, Simon Fraser simon.fra...@apple.comwrote:
Put
* {
-webkit-user-select: none;
}
in
On Oct 19, 2010, at 10:07 AM, Efan... wrote:
Hi All unfortunately I can not use JAVA script or any thing like that cause
my application is totally c++ , QT based.
I need to make the change in webkit src code I guess.
Note that this is already supported (with no source changes) on Mac OS X
On Mon, Oct 18, 2010 at 8:22 PM, Alex Milowski a...@milowski.org wrote:
In cases where specialized render objects (typically with display
inline-block) are used (e.g. an operator), the assert fires:
a href='#'
math xmlns='http://www.w3.org/1998/Math/MathML'mox/mo/math
/a
The culprit in
Hi,
I think I talked with this person on IRC last night, and I suggested him to
modify EditorClientQt::shouldChangeSelectedRange to always return false.
FYI, there is a bug to add this feature on Qt ports:
https://bugs.webkit.org/show_bug.cgi?id=38520
- Ryosuke
On Tue, Oct 19, 2010 at 10:17
Thanks, Ryosuke.
Done. https://bugs.webkit.org/show_bug.cgi?id=47911
Jenn
On Tue, Oct 19, 2010 at 9:37 AM, Ryosuke Niwa rn...@webkit.org wrote:
Submit a patch to modify this page:
http://trac.webkit.org/browser/trunk/WebKitSite/building/tools.html
- Ryosuke
On Tue, Oct 19, 2010 at 9:30
On Tue, Oct 19, 2010 at 8:42 AM, Alexey Proskuryakov a...@webkit.org wrote:
15.10.2010, в 07:39, Eric Seidel написал(а):
BTW, the commit-queue has started complaining publicly about flaky tests:
https://bugs.webkit.org/show_bug.cgi?id=47698#c5
Hopefully this will bring further awareness to
(1) Make sure any layout methods you call do setNeedsLayout(false) at the end
of them.
(2) Look for any early returns in any of your layout methods, since maybe you
did an early return causing the setNeedsLayout(false) to be missed.
(3) Make sure you aren't dirtying a child for a re-layout
19.10.2010, в 11:16, Adam Barth написал(а):
Also, these bugs are close to the end of their
lifecycle (because their patch is about to land), so they shouldn't
generate more than 3 or 4 emails each. That boils down to about one
or two emails per week for the flakiest test.
One e-mail (per
On Tue, Oct 19, 2010 at 11:44 AM, Alexey Proskuryakov a...@webkit.org wrote:
I agree that raising awareness of which tests or code areas are flaky seems
useful. One problem I personally had was with digging up data on flakiness.
The link for a dashboard that I found was
On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com wrote:
(1) Make sure any layout methods you call do setNeedsLayout(false) at the end
of them.
(2) Look for any early returns in any of your layout methods, since maybe you
did an early return causing the setNeedsLayout(false) to
The bug 38520 https://bugs.webkit.org/show_bug.cgi?id=38520 addresses the
exact problem.
- Ryosuke
On Tue, Oct 19, 2010 at 11:28 AM, Efan... efanhar...@gmail.com wrote:
Ah might be Raving Jason would have had word with you, he is my colleague
he told me on skype today to do the same, return
webkit-patch find-flaky-tests can also show you what tests are
recently flaky, but its not as nice as the dashboard.
-eric
On Tue, Oct 19, 2010 at 12:06 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Oct 19, 2010 at 11:44 AM, Alexey Proskuryakov a...@webkit.org wrote:
I agree that raising
On Oct 19, 2010, at 2:07 PM, Alex Milowski wrote:
On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com wrote:
(1) Make sure any layout methods you call do setNeedsLayout(false) at the
end of them.
(2) Look for any early returns in any of your layout methods, since maybe
you did an
On Tue, Oct 19, 2010 at 11:44 AM, Alexey Proskuryakov a...@webkit.org wrote:
19.10.2010, в 11:16, Adam Barth написал(а):
Also, these bugs are close to the end of their
lifecycle (because their patch is about to land), so they shouldn't
generate more than 3 or 4 emails each. That boils down to
19.10.2010, в 12:33, Adam Barth написал(а):
Maybe the thing to do is CC the author of the flaky test for the one
bug comment and then immediately unCC them. That way they don't see
the rest of the traffic on the bug.
That would still be two e-mails about a bug the person otherwise doesn't
On Tue, Oct 19, 2010 at 12:41 PM, Alexey Proskuryakov a...@webkit.org wrote:
19.10.2010, в 12:33, Adam Barth написал(а):
Maybe the thing to do is CC the author of the flaky test for the one
bug comment and then immediately unCC them. That way they don't see
the rest of the traffic on the bug.
On Tue, Oct 19, 2010 at 1:30 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Oct 19, 2010 at 12:41 PM, Alexey Proskuryakov a...@webkit.org
wrote:
19.10.2010, в 12:33, Adam Barth написал(а):
Maybe the thing to do is CC the author of the flaky test for the one
bug comment and then
Also, if your pattern of code in a layout method is
(1) Call base class RenderBlock::layout
(2) Do other stuff that might cause dirtying
Then you should really bulletproof that code by adding
(1) Call base class RenderBlock::layout
(2) Do a setChildNeedsLayout(true, false) on yourself just to
On Oct 19, 2010, at 1:30 PM, Adam Barth wrote:
On Tue, Oct 19, 2010 at 12:41 PM, Alexey Proskuryakov a...@webkit.org wrote:
19.10.2010, в 12:33, Adam Barth написал(а):
Maybe the thing to do is CC the author of the flaky test for the one
bug comment and then immediately unCC them. That way
On Tue, Oct 19, 2010 at 1:45 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 19, 2010, at 1:30 PM, Adam Barth wrote:
On Tue, Oct 19, 2010 at 12:41 PM, Alexey Proskuryakov a...@webkit.org
wrote:
19.10.2010, в 12:33, Adam Barth написал(а):
Maybe the thing to do is CC the author of the flaky
On Tue, Oct 19, 2010 at 1:51 PM, Adam Barth aba...@webkit.org wrote:
Another option is to file a new bug about the flakiness and ping that
bug when we observe the test flake out.
I've considered this before. We'd have to write a bit of bugzilla.py
code to make this work though. :)
That's
Sorry, wrong account.
On Tue, Oct 19, 2010 at 1:59 PM, Eric Seidel esei...@google.com wrote:
On Tue, Oct 19, 2010 at 1:45 PM, Maciej Stachowiak m...@apple.com wrote:
It looks like the bot is adding a comment to the bug with the patch that was
being processed when flakiness was detected, not
On Tue, Oct 19, 2010 at 1:44 PM, David Hyatt hy...@apple.com wrote:
Also, if your pattern of code in a layout method is
(1) Call base class RenderBlock::layout
(2) Do other stuff that might cause dirtying
Then you should really bulletproof that code by adding
(1) Call base class
FWIW, I needed NRWT to support --tolerance for something else today
(mainly because when using it with the Mac port, it defaults to 0.1
tolerance, with no way to override it), so I added NRWT support for
it: http://webkit.org/b/47959.
Mihai
On Thu, Oct 14, 2010 at 2:44 PM, Dirk Pranke
By the way could there be any way like -webkit-user-select = none, where I
can select the element Withought highlighting??
On Tue, Oct 19, 2010 at 12:08 PM, Ryosuke Niwa rn...@webkit.org wrote:
The bug 38520 https://bugs.webkit.org/show_bug.cgi?id=38520 addresses
the exact problem.
- Ryosuke
40 matches
Mail list logo
