Bug 14524 - Web Inspector should be usable as a reduction engine
Summary: Web Inspector should be usable as a reduction engine
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Enhancement
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks: 18690
  Show dependency treegraph
 
Reported: 2007-07-04 12:01 PDT by Gavin Sherlock
Modified: 2015-08-04 09:41 PDT (History)
5 users (show)

See Also:


Attachments
Stand-alone tool for reducing bugs (15.47 KB, application/x-download)
2008-05-15 15:22 PDT, David Kilzer (:ddkilzer)
no flags Details
Stand-alone tool for reducing bugs v2 (15.76 KB, application/x-download)
2010-03-30 16:29 PDT, David Kilzer (:ddkilzer)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gavin Sherlock 2007-07-04 12:01:28 PDT
When I report a bug, I don't have the skill or the time to make a reduction.  However, if the web inspector allowed me to do this easily, I would be much more likely to make an attempt.  E.g. right clicking on part of a page could have a menu item of "Inspect Element for Reduction", indicating that the thing you were clicking on had some kind of layout bug.  Then, in docked mode, the Inspector could successively strip away parts of the page, asking you if the layout problem was still visible, with the goal of reducing the page to a bare minimum containing only those parts sufficient and necessary to still show the incorrect behavior (possibly with the original text replaced with lorem ipsum content, for privacy reasons).  It could then let you save the reduced version, for submission to bugzilla.  I'm sure this is non-trivial to engineer, but it sure would be a useful tool.
Comment 1 Timothy Hatcher 2007-11-15 22:15:46 PST
Landed in r27839. http://trac.webkit.org/projects/webkit/changeset/27839
Comment 2 Timothy Hatcher 2007-11-15 22:16:06 PST
Wrong bug.

Comment 3 David Kilzer (:ddkilzer) 2007-11-16 05:51:15 PST
Instead of manually verifying the bug (e.g., asking the user if the bug still reproduces on each iteration), a JavaScript test method could be used that returns true if the bug still reproduces after a change or false otherwise.

An algorithm similar to the "delta debug" algorithm <http://www.st.cs.uni-sb.de/dd/> could be used with DOM operations such as:

- Removing DOM nodes
- Removing stylesheet rules
- Removing DOM node attributes
- Removing individual properties from style rules (in stylesheets and on DOM nodes)
Comment 4 Adam Roben (:aroben) 2008-01-29 11:16:31 PST
<rdar://problem/5712941>
Comment 5 David Kilzer (:ddkilzer) 2008-05-15 15:22:13 PDT
Created attachment 21184 [details]
Stand-alone tool for reducing bugs

Here's a WIP copy of a tool (a web page) that works on a certain class of test case reductions, e.g., ones that you can easily write a test for using JavaScript.  Repaint issues would not work (because you can't tell if the repaint failed via JavaScript), but "an element is misplaced on the page" or "an element is too big/too small" issues work well.

Here's how to use it.

* SETUP
1. Save as "Page Source" the page you want to reduce into the same directory as index.html.
2. Edit pageSource.html to add a <base href=""> tag with the original URL of the page.
3. Edit <iframe> at bottom of index.html to point to pageSource.html.
4. Edit pageSource.html to add id attributes to "interesting" elements.
5. Open index.html (through a web server or through the file system) in Safari.
6. Write JavaScript code to test for the interesting condition you're seeing.  (I've used offsetTop and offsetLeft with a lot of success to verify the relative position of two elements that I suspect are involved.)  Notes:
- The "document" variable is the document for the iframe, not the document for index.html.
- If you don't want a node (element or text) to disappear, add a check for it in the test function to make sure false is returned if it's not found in the DOM.
7. Use the "Verify Test" button to make sure your JavaScript test returns true for the existing web page.

* RUNNING
At this point, you have 3 tools that may be used multiple times in any order to reduce a web page:  "Run Child Node Delta", "Run Tree Node Delta" and "Run StyleSheet Delta".  The "View HTML" button pops a JavaScript alert with the current contents of the iframe which you may cut/paste after selecting all (even if it runs off the screen).

"Run Child Node Delta"
This button walks the DOM attempting to remove all child nodes at levels N to M below the document root (<html>) where "N" is the starting level and "M" is the maximum tree depth of the DOM.  It starts at the value in the "Level" input box, so if you've run it once, you'll need to reset it to 1 (or whatever) to run it again.  (Obviously, it only removes the node if the test() method returns true.)

This was the original tool I wrote and works fairly well.  You tend to be left with large single-branch trees due to the nature of the reductions, but those are easily reduced by hand.

Also note that sometimes removing style/link elements will not trigger proper redraws, so it's useful to start at Level "3" or "4" if the resulting reduction doesn't reproduce when you reload it.

"Run Tree Node Delta"
This button attempts to reduce the tree depth by removing nodes who have only a single child.  It doesn't work very well; perhaps it needs to walk child nodes from the bottom of the tree up, or be more intelligent about removing some types of nodes (like tables).

"Run StyleSheet Delta"
This button "flattens" stylesheets used in an HTML document, and replaces all <link> and <style> nodes with local copies of the rules.  Then it iterates through all rules in all stylesheets attempting to remove them as long as the test() method still returns true.

* SAVE THE HTML
When you think the tool has done as much as it can, use the "View HTML" button and copy/paste the HTML into a local file for further reduction.  (Yes, you can actually copy/paste HTMl from the JavaScript dialog in Safari.  Opening a new window with the source would be a bit nicer.)

* NOTES
I've used it to reduce test cases for these bugs already:

http://bugs.webkit.org/show_bug.cgi?id=15770
http://bugs.webkit.org/show_bug.cgi?id=15782
http://bugs.webkit.org/show_bug.cgi?id=15831
http://bugs.webkit.org/show_bug.cgi?id=15956

My git repo hash: c00c22539450c2f2b4691b9aaefd779d503516ca
Comment 6 David Kilzer (:ddkilzer) 2010-03-30 16:29:44 PDT
Created attachment 52097 [details]
Stand-alone tool for reducing bugs v2

Minor update to work with more secure WebKit that doesn't leak Element prototypes from the main document into an iframe document.

My git repo hash:  fa965920ffc7b1c7d2f1a35cc23349e2c4b908ff
Comment 7 Joe Thomas 2010-08-17 16:54:30 PDT
This is a very interesting line of work. Perhaps a bookmarklet is in order?
Comment 8 BJ Burg 2014-01-12 11:19:57 PST
This would be way cooler and work better if it could use web replay! :) I don't know if it would be an inspector feature, standalone, or browser feature though. For now, putting into Tools component.