Bug 118676 - Web Inspector: Master bug for moving to the new inspector on all ports
Summary: Web Inspector: Master bug for moving to the new inspector on all ports
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on: 119559 120098 120647
Blocks: 120609 118677 118678 118715 118959 119252 120657 122294 122295 122647
  Show dependency treegraph
 
Reported: 2013-07-15 09:46 PDT by Roland Takacs
Modified: 2014-01-11 18:27 PST (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Takacs 2013-07-15 09:46:31 PDT
As you know we should use the Safari inspector UI (Source/WebInspectorUI) inspead of the old one (Source/WebCore/inspector/front-end).
In this place all ports can track the bugs that related to the Safari inspector UI integration.
Comment 1 Radar WebKit Bug Importer 2013-07-15 09:47:12 PDT
<rdar://problem/14444151>
Comment 2 Seokju Kwon 2013-07-16 02:12:58 PDT
I wonder whether 'New Web Inspector' can pass LayoutTest related to Inspector or not.
Comment 3 Timothy Hatcher 2013-07-16 10:04:03 PDT
(In reply to comment #2)
> I wonder whether 'New Web Inspector' can pass LayoutTest related to Inspector or not.

It can't. We plan to make a new test harness soon.
Comment 4 Marcelo Morais 2013-10-02 12:17:04 PDT
Hello, now that efl/gtk/mac/win use the new inspector, I would like to start removing the old code (qt was the last port with the old inspector, and is being removed from trunk), is that ok for you guys?
Comment 5 Timothy Hatcher 2013-10-02 13:12:49 PDT
Yes! The only question about removing the old is test coverage. It would be nice to convert some of the old Inspector UI tests over to protocol tests. (We don't plan to do any UI testing of the new Inspector but we want to test the protocol.)
Comment 6 Marcelo Morais 2013-10-02 14:35:20 PDT
(In reply to comment #5)
> Yes! The only question about removing the old is test coverage. It would be nice to convert some of the old Inspector UI tests over to protocol tests. (We don't plan to do any UI testing of the new Inspector but we want to test the protocol.)

I see... have you decided which tests should be converted?

How can we proceed? Maybe creating separated bugs, one to remove the old front end and another to convert these tests and remove the rest? Suggestions?
Comment 7 Marcelo Morais 2013-10-03 14:10:10 PDT
Hi again, I created the bugs 122294 and 122295, one to remove the old front-end and another to check which UI tests can be converted.

I will remove the old front end first and leave the tests untouched.

I don't know if you already thought about which tests should be converted, if you don't maybe I can take a look at this later, I think that would be a good opportunity to me to learn about this. 

Is that ok for you?
Comment 8 Joseph Pecoraro 2013-10-03 14:36:32 PDT
(In reply to comment #7)
> Hi again, I created the bugs 122294 and 122295, one to remove the old front-end and another to check which UI tests can be converted.
> 
> I will remove the old front end first and leave the tests untouched.

If you remove the old frontend you will need to skip all of the LayoutTests/inspector and LayoutTests/http/tests/inspector tests on all platforms, because they rely on running code inside the old frontend.


> I don't know if you already thought about which tests should be converted, if you don't maybe I can take a look at this later, I think that would be a good opportunity to me to learn about this. 
> 
> Is that ok for you?

I think this is fine. It would be nice to have a strategy for converting over tests. We haven't really had much time to think about this.

Ideally we would have at least one test for each protocol method, then perhaps extra tests for cases involving multiple back and forths between a frontend and backend.

In the process of writing the new tests we can remove old tests that tested the same protocol methods. You mention you are interested, it would be nice to talk a small piece of the protocol, maybe the Storage domain, and write new tests for that. I think it would be a nice small task, and we can see from there how easy / difficult it would be to convert the rest.

I started working on the Debugger domain. See LayoutTests/inspector-protocol/debugger as an example on how to structure and write the tests.
Comment 9 Marcelo Morais 2013-10-04 07:41:04 PDT
> If you remove the old frontend you will need to skip all of the LayoutTests/inspector and LayoutTests/http/tests/inspector tests on all platforms, because they rely on running code inside the old frontend.
>

Yes, I'll do this.


> I think this is fine. It would be nice to have a strategy for converting over tests. We haven't really had much time to think about this.
> 
> Ideally we would have at least one test for each protocol method, then perhaps extra tests for cases involving multiple back and forths between a frontend and backend.
> 
> In the process of writing the new tests we can remove old tests that tested the same protocol methods. You mention you are interested, it would be nice to talk a small piece of the protocol, maybe the Storage domain, and write new tests for that. I think it would be a nice small task, and we can see from there how easy / difficult it would be to convert the rest.
> 
> I started working on the Debugger domain. See LayoutTests/inspector-protocol/debugger as an example on how to structure and write the tests.

Nice, I'll take a look at this. Like I said it is a good opportunity to learn and I want to help. :)
Comment 10 BJ Burg 2014-01-11 18:27:31 PST
Since this bug was created, I believe all ports have moved to the new inspector or have dropped out of trunk. There are still follow-up bugs for converting skipped inspector UI tests into inspector protocol tests. But, this master bug doesn't seem to 'block' anything now.