Bug 83998

Summary: Capture CSS parser context
Product: WebKit Reporter: Antti Koivisto <koivisto@iki.fi>
Component: CSSAssignee: Nobody <webkit-unassigned@lists.webkit.org>
Status: RESOLVED FIXED    
Severity: Normal CC: akling@apple.com, alexis@webkit.org, dglazkov@chromium.org, eric.carlson@apple.com, eric@webkit.org, feature-media-reviews@chromium.org, macpherson@chromium.org, sam@webkit.org, webkit.review.bot@gmail.com, zarvai@inf.u-szeged.hu
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 84013    
Bug Blocks: 77745    
Attachments:
Description Flags
patch
none
rebased
webkit.review.bot: commit‑queue-
try to fix chromium build
webkit.review.bot: commit‑queue-
Archive of layout-test-results from ec2-cr-linux-03
none
modify the failing tests to not expect settings to change the behavior of the existing stylesheets akling: review+

Description From 2012-04-15 09:13:37 PST
Currently the CSS parser calls to the Document and StyleSheetInternal objects to get settings, base URL etc. The required information should be passed in on parser construction instead. The parser should not need to know about Document at all.
------- Comment #1 From 2012-04-15 09:25:09 PST -------
Created an attachment (id=137237) [details]
patch
------- Comment #2 From 2012-04-15 09:38:02 PST -------
Created an attachment (id=137238) [details]
rebased
------- Comment #3 From 2012-04-15 09:40:12 PST -------
Attachment 137238 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/css/CSSParser.h:329:  The parameter name "context" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 23 files


If any of these errors are false positives, please file a bug against check-webkit-style.
------- Comment #4 From 2012-04-15 10:10:06 PST -------
(From update of attachment 137238 [details])
Attachment 137238 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12405802
------- Comment #5 From 2012-04-15 10:17:54 PST -------
Created an attachment (id=137239) [details]
try to fix chromium build
------- Comment #6 From 2012-04-15 11:17:13 PST -------
(From update of attachment 137239 [details])
Attachment 137239 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12406713

New failing tests:
fast/regions/css-regions-disabled.html
css3/filters/custom/custom-filter-property-parsing.html
------- Comment #7 From 2012-04-15 11:17:19 PST -------
Created an attachment (id=137240) [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
------- Comment #8 From 2012-04-15 12:14:26 PST -------
Created an attachment (id=137242) [details]
modify the failing tests to not expect settings to change the behavior of the existing stylesheets
------- Comment #9 From 2012-04-15 16:08:10 PST -------
Are there any cases where we keep a CSSParser object around for a while?  Are we sure the baseURL of the Document can never change in the lifetime of the parser?
------- Comment #10 From 2012-04-15 19:07:48 PST -------
(In reply to comment #9)
> Are there any cases where we keep a CSSParser object around for a while?  

No. It is always stack allocated and thrown away after parsing finishes.

> Are we sure the baseURL of the Document can never change in the lifetime of the parser?

Pretty sure.
------- Comment #11 From 2012-04-15 19:29:30 PST -------
(From update of attachment 137242 [details])
r=me.
------- Comment #12 From 2012-04-15 19:47:16 PST -------
http://trac.webkit.org/changeset/114217
------- Comment #13 From 2012-04-15 20:49:06 PST -------
Is this in preparation for moving CSSParsing off into another thread?  Just curious, as we've discussed such for the HTML parser.
------- Comment #14 From 2012-04-15 21:00:52 PST -------
(In reply to comment #13)
> Is this in preparation for moving CSSParsing off into another thread?  Just curious, as we've discussed such for the HTML parser.

This is prep work for sharable style sheets (see the meta bug I just added as a dependent.)

Moving CSS parsing to a secondary thread is certainly made easier by this effort, but not currently a goal in itself.
------- Comment #15 From 2012-04-16 01:31:36 PST -------
(In reply to comment #12)
> http://trac.webkit.org/changeset/114217

It seems after the commit 
fast/repaint/line-flow-with-floats-in-regions.html
layout test fails on Qt Release bots

http://build.webkit.org/results/Qt%20Linux%20Release/r114217%20%2845824%29/fast/repaint/line-flow-with-floats-in-regions-pretty-diff.html