[webkit-dev] HA: Problem with -webkit-gradient css option on MIPS platform.

[Pushkin Andrei]

I test more and find that bug reproduced in all gtk2 native elements (button, 
inputbox etc), but not reproduced in all not native elements (div). How I can 
debug it? What part of code I need to look up?

Andrei Pushkin

От: mmaxfi...@apple.com [mmaxfi...@apple.com]
Отправлено: 29 сентября 2015 г. 23:37
Кому: Pushkin Andrei
Копия: webkit-dev@lists.webkit.org
Тема: Re: [webkit-dev] Problem with -webkit-gradient css option on MIPS 
platform.

Are you sure that the two versions of webkit are exactly the same? Same 
operating system, same port, same SVN revision?

AFAIK, WebKit itself has no concept of "1.10." That version number belongs to 
whichever project you are getting WebKit from. That project may have built 
WebKit on the two different platforms differently. (Someone else on the team: 
Please correct me if I'm wrong.)

--Myles

On Sep 29, 2015, at 8:35 AM, Pushkin Andrei 
> wrote:

Hi. I have embedded Linux MIPS board with webkit 1.10.
This code does not work on my MIPS board (-webkit-gradient is ignored):
ABC
But work in my x86 PC on same version of webkit.

This code work fine in all platforms:
ABC

Andrei Pushkin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removal of mediagroup/MediaController from HTML

[Edward O'Connor]

Hi Anne,

You wrote:

> Hi,
>
> The WHATWG is considering removing mediagroup/MediaController from
> HTML, since other than WebKit no browser project has expressed
> interest in this feature.
>
> https://github.com/whatwg/html/issues/192 is the corresponding issue.
>
> I would recommend following up in the issue itself if this is
> problematic or if the WHATWG is forgetting something.

Thanks for the heads up. Eric & I have followed up there and will
continue to monitor the issue.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

[Vienneau, Christopher]

Hey Guys,

I'm redirecting Rupali's enquiry about WebInspector's Debugger and WinCairo to 
a new audience.  I came across this again the other day, I think all the debug 
information Rupali provided is still accurate for our current state.  In brief, 
when a breakpoint is hit in the debugger the pane that should show the source 
gets stuck as a circular time spinner.  This blocks a lot of functionality sine 
you can't see what you're debugging.  We would appreciate any tips on how to 
resolve this in WinCairo since our port behaves the same way.

Thanks

Chris

From: webkit-help-boun...@lists.webkit.org 
[mailto:webkit-help-boun...@lists.webkit.org] On Behalf Of Sharma, Rupali
Sent: Monday, August 31, 2015 11:34 AM
To: Sharma, Rupali ; webkit-h...@lists.webkit.org
Subject: Re: [webkit-help] Issue with Web Inspector debugger breakpoint 
handling (on Wincairo)

Hi folks,

Are you aware of this issue with web Inspector which we see on WinCairo?

Thanks,
Rupali

From: 
webkit-help-boun...@lists.webkit.org
 [mailto:webkit-help-boun...@lists.webkit.org] On Behalf Of Sharma, Rupali
Sent: Wednesday, August 26, 2015 11:16 AM
To: webkit-h...@lists.webkit.org
Subject: [webkit-help] Issue with Web Inspector debugger breakpoint handling 
(on Wincairo)

Hello,

We are seeing an issue with the Web Inspector debugger on latest WinCairo [ 
using Webkit r188436]. In the wincairo webinpector, whenever a breakpoint is 
set and then web page reload on a javascript source, the view goes on into some 
indefinite waiting and never shows up, until we press continue-script-execution 
or another page-refresh.

Here are the simple steps to reproduce it,

1.   Launch WinCairo and go to google.com

2.   Open Web inspector and open the script source of any .js script

3.   Set a breakpoint anywhere

4.   Reload the web page

What we see is the spinner spinning and never the script source. However, if 
one presses continue-script-execution from the debugger controls, we get the 
view back.

Some points of debugging we did at our end,
(i) We did some digging around the breakpoint setting, and do see the flow 
correctly being going to handlepause() of the ScriptDebugServer. Though I see 
the vmEntryGlobalObject is not updated with any value or callframe.
I did not see any abnormality in the listener dispatching callback, with the 
correct pause-reason to pass i.e. Breakpoint. However, I am not sure if its 
sending the right pause-data to the frontend.

(ii)It gets stuck in the infinite eventloop which does look fine to me, as long 
as it is paused.

(iii)Another observation I see is, the message "TimelineRecordingStopped" being 
sent to the frontend. I believe, this is something newly added and not sure, if 
at all it'll effect the debugger scriptsource in any way. [reference : 
doDispatchMessageOnFrontendPage]

(iv)Coming onto the Web inspector UI side of story, I did see one bug, that 
even though  the method in DebuggerManager.js  "debuggerDidPause" got the right 
pause-reason from the webkit, its not able to pass on correctly due to an 
apparent bug in
_pauseReasonFromPayload: function(payload)
Here, the input payload does not match any of the  DebuggerAgent.PausedReason 
and hence falls to the error of unknown reason. The correct string to match 
would be "Breakpoint". However, correcting the flow still doesn't give us any 
favorable behavior. Though, I believe it's good to know.

Would you have a better insight as to what exactly is blocking the script 
source to display in the paused-state of web inspector debugger?

The output log looks like:
EAWebKit:Event kLETResourceResponseReceived : The server has responded to a 
resource request URL - http://www.google.com/ with status = 200
EAWebKit:Event kLETLoadCompletedWithoutErrors : The load is completed without 
errors
Total Page Loaded : 1.139
Total Page Lib Tick Update  : 0.604 
 Slowest:: 0.521
Total Page View Tick Update   : 0.000  Slowest:: 0.000
Total Page Network Tick Update: 0.000
Total Jobs Loop   : 0.503  Slowest:: 0.489
Total Page Script : 0.000  Slowest:: 0.000
Font Glyph Draw   : 0.000
Bitmap Image Draw : 0.000
Bitmap Image Decoder  : 0.000
Image Compression : 0.000
Font/Image Raster Draw: 0.000
TH Connect: 0.000
TH Transfer   : 0.000
TH Disconnect : 0.000
TH Size   : 0
TH Files  : 0
Cached Connect: 0.000
Cached Transfer   : 0.000
Cached Disconnect : 0.000
Cached Size   : 0
Cached files  : 0
Java Script Parse   

Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

[Brian Burg]

If this reproduces on tip-of-tree WinCairo in the WebKit repository, then you 
should file a Web Inspector/WinCairo bug in Bugzilla and continue this 
discussion there.
I really have no way of knowing what’s going on just by reading these steps. 
You could also try reaching the relevant folks on IRC (#webkit or 
#webkit-inspector).

-Brian

> On Oct 2, 2015, at 1:29 PM, Vienneau, Christopher  wrote:
> 
> Hey Guys,
>  
> I’m redirecting Rupali’s enquiry about WebInspector’s Debugger and WinCairo 
> to a new audience.  I came across this again the other day, I think all the 
> debug information Rupali provided is still accurate for our current state.  
> In brief, when a breakpoint is hit in the debugger the pane that should show 
> the source gets stuck as a circular time spinner.  This blocks a lot of 
> functionality sine you can’t see what you’re debugging.  We would appreciate 
> any tips on how to resolve this in WinCairo since our port behaves the same 
> way.
>  
> Thanks
>  
> Chris
>  
> From: webkit-help-boun...@lists.webkit.org 
>  
> [mailto:webkit-help-boun...@lists.webkit.org 
> ] On Behalf Of Sharma, Rupali
> Sent: Monday, August 31, 2015 11:34 AM
> To: Sharma, Rupali >; 
> webkit-h...@lists.webkit.org 
> Subject: Re: [webkit-help] Issue with Web Inspector debugger breakpoint 
> handling (on Wincairo)
>  
> Hi folks,
>  
> Are you aware of this issue with web Inspector which we see on WinCairo?
>  
> Thanks,
> Rupali
>  
> From: webkit-help-boun...@lists.webkit.org 
>  
> [mailto:webkit-help-boun...@lists.webkit.org 
> ] On Behalf Of Sharma, Rupali
> Sent: Wednesday, August 26, 2015 11:16 AM
> To: webkit-h...@lists.webkit.org 
> Subject: [webkit-help] Issue with Web Inspector debugger breakpoint handling 
> (on Wincairo)
>  
> Hello,
>  
> We are seeing an issue with the Web Inspector debugger on latest WinCairo [ 
> using Webkit r188436]. In the wincairo webinpector, whenever a breakpoint is 
> set and then web page reload on a javascript source, the view goes on into 
> some indefinite waiting and never shows up, until we press 
> continue-script-execution or another page-refresh.
>  
> Here are the simple steps to reproduce it,
> 1.   Launch WinCairo and go to google.com 
> 2.   Open Web inspector and open the script source of any .js script
> 3.   Set a breakpoint anywhere
> 4.   Reload the web page
>  
> What we see is the spinner spinning and never the script source. However, if 
> one presses continue-script-execution from the debugger controls, we get the 
> view back.
>  
> Some points of debugging we did at our end,
> (i) We did some digging around the breakpoint setting, and do see the flow 
> correctly being going to handlepause() of the ScriptDebugServer. Though I see 
> the vmEntryGlobalObject is not updated with any value or callframe.
> I did not see any abnormality in the listener dispatching callback, with the 
> correct pause-reason to pass i.e. Breakpoint. However, I am not sure if its 
> sending the right pause-data to the frontend.
>  
> (ii)It gets stuck in the infinite eventloop which does look fine to me, as 
> long as it is paused.
>  
> (iii)Another observation I see is, the message “TimelineRecordingStopped” 
> being sent to the frontend. I believe, this is something newly added and not 
> sure, if at all it’ll effect the debugger scriptsource in any way. [reference 
> : doDispatchMessageOnFrontendPage]
>  
> (iv)Coming onto the Web inspector UI side of story, I did see one bug, that 
> even though  the method in DebuggerManager.js  “debuggerDidPause” got the 
> right pause-reason from the webkit, its not able to pass on correctly due to 
> an apparent bug in
> _pauseReasonFromPayload: function(payload)
> Here, the input payload does not match any of the  DebuggerAgent.PausedReason 
> and hence falls to the error of unknown reason. The correct string to match 
> would be “Breakpoint”. However, correcting the flow still doesn’t give us any 
> favorable behavior. Though, I believe it’s good to know.
>  
> Would you have a better insight as to what exactly is blocking the script 
> source to display in the paused-state of web inspector debugger?
>  
> The output log looks like:
> EAWebKit:Event kLETResourceResponseReceived : The server has responded to a 
> resource request URL - http://www.google.com/  with 
> status = 200
> EAWebKit:Event kLETLoadCompletedWithoutErrors : The load is completed without 
> errors
> Total Page Loaded : 1.139
> Total Page Lib Tick Update  : 
> 0.604  Slowest:: 0.521
> Total Page View Tick Update

Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

[Joseph Pecoraro]

> Here are the simple steps to reproduce it,
> 1.   Launch WinCairo and go to google.com 
> 2.   Open Web inspector and open the script source of any .js script
> 3.   Set a breakpoint anywhere
> 4.   Reload the web page
>  
> What we see is the spinner spinning and never the script source. However, if 
> one presses continue-script-execution from the debugger controls, we get the 
> view back.

Is WinCairo using WebKit1 or WebKit2?

This sounds like a known issue with WebKit1 where the inspector frontend page 
lives in the same process as the inspected page. In this situation pausing a 
page prevents Promise reactions from firing in the inspector frontend page. 
Loading resource content in the frontend depends on Promises. This should not 
be a problem in a WebKit2 world where the inspector frontend page lives in a 
separate process.

- Joe___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

[Alex Christensen]

> On Oct 2, 2015, at 3:12 PM, Joseph Pecoraro  wrote:
> Is WinCairo using WebKit1 or WebKit2?
Windows is WebKit1-only.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

[Vienneau, Christopher]

WinCairo and our port are both WebKit1, so your suggestion sounds quite 
plausible.  On our port we also hooked up remote WebInpsector but it suffers 
from the same issue, due to the way its hooked up I think it would be pretty 
much with WebKit1 way of doing things here too.  Are there any suggestions on 
how we might verify and workaround this issue?

Chris

From: pecor...@apple.com [mailto:pecor...@apple.com]
Sent: Friday, October 02, 2015 3:12 PM
To: Vienneau, Christopher 
Cc: WebKit Development ; Alex Christensen 
; Sharma, Rupali 
Subject: Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger 
breakpoint handling (on Wincairo)

Here are the simple steps to reproduce it,
1.   Launch WinCairo and go to google.com
2.   Open Web inspector and open the script source of any .js script
3.   Set a breakpoint anywhere
4.   Reload the web page

What we see is the spinner spinning and never the script source. However, if 
one presses continue-script-execution from the debugger controls, we get the 
view back.

Is WinCairo using WebKit1 or WebKit2?

This sounds like a known issue with WebKit1 where the inspector frontend page 
lives in the same process as the inspected page. In this situation pausing a 
page prevents Promise reactions from firing in the inspector frontend page. 
Loading resource content in the frontend depends on Promises. This should not 
be a problem in a WebKit2 world where the inspector frontend page lives in a 
separate process.

- Joe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

[Joseph Pecoraro]

I suggest reopening and restarting investigation on:
 Promise reactions in the Inspector page do not 
run when the debugger is paused on the inspected page

The bug already has some analysis. You could use that to verify if your case is 
the same and investigate a fix. Since the time that bug was closed Promises 
have been used in other places in the inspector, so WebKit1 inspection may 
suffer from other more subtle issues with the same cause.

Further communication can happen in the bugzilla bug.

- Joe

> On Oct 2, 2015, at 4:20 PM, Vienneau, Christopher  wrote:
> 
> WinCairo and our port are both WebKit1, so your suggestion sounds quite 
> plausible.  On our port we also hooked up remote WebInpsector but it suffers 
> from the same issue, due to the way its hooked up I think it would be pretty 
> much with WebKit1 way of doing things here too.  Are there any suggestions on 
> how we might verify and workaround this issue?
>  
> Chris
>  
> From: pecor...@apple.com [mailto:pecor...@apple.com] 
> Sent: Friday, October 02, 2015 3:12 PM
> To: Vienneau, Christopher 
> Cc: WebKit Development ; Alex Christensen 
> ; Sharma, Rupali 
> Subject: Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger 
> breakpoint handling (on Wincairo)
>  
> Here are the simple steps to reproduce it,
> 1.   Launch WinCairo and go to google.com 
> 2.   Open Web inspector and open the script source of any .js script
> 3.   Set a breakpoint anywhere
> 4.   Reload the web page
>  
> What we see is the spinner spinning and never the script source. However, if 
> one presses continue-script-execution from the debugger controls, we get the 
> view back.
>  
> Is WinCairo using WebKit1 or WebKit2?
>  
> This sounds like a known issue with WebKit1 where the inspector frontend page 
> lives in the same process as the inspected page. In this situation pausing a 
> page prevents Promise reactions from firing in the inspector frontend page. 
> Loading resource content in the frontend depends on Promises. This should not 
> be a problem in a WebKit2 world where the inspector frontend page lives in a 
> separate process.
>  
> - Joe

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev