WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
51679
Web Inspector: A disabled style property should get enabled when edited
https://bugs.webkit.org/show_bug.cgi?id=51679
Summary
Web Inspector: A disabled style property should get enabled when edited
Alexander Pavlov (apavlov)
Reported
2010-12-28 08:33:44 PST
In the Styles sidebar, a changed disabled CSS property remains disabled, while Firebug enables it when the new value is applied.
Attachments
[PATCH] Suggested solution
(5.91 KB, patch)
2010-12-28 11:07 PST
,
Alexander Pavlov (apavlov)
no flags
Details
Formatted Diff
Diff
[PATCH] propertyText change computation fixed
(6.03 KB, patch)
2010-12-29 02:55 PST
,
Alexander Pavlov (apavlov)
pfeldman
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Alexander Pavlov (apavlov)
Comment 1
2010-12-28 11:07:17 PST
Created
attachment 77562
[details]
[PATCH] Suggested solution
Pavel Feldman
Comment 2
2010-12-28 23:01:06 PST
Comment on
attachment 77562
[details]
[PATCH] Suggested solution View in context:
https://bugs.webkit.org/attachment.cgi?id=77562&action=review
> WebCore/inspector/front-end/CSSStyleModel.js:474 > + if (newProperty && this.disabled && !propertyText.match(/^\s*$/) && (!this.property || newProperty.propertyText !== this.property.propertyText)) {
What is "this.property" and where does it get defined?
Alexander Pavlov (apavlov)
Comment 3
2010-12-29 02:35:25 PST
(In reply to
comment #2
)
> (From update of
attachment 77562
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=77562&action=review
> > > WebCore/inspector/front-end/CSSStyleModel.js:474 > > + if (newProperty && this.disabled && !propertyText.match(/^\s*$/) && (!this.property || newProperty.propertyText !== this.property.propertyText)) { > > What is "this.property" and where does it get defined?
It is the WebInspector.CSSProperty that lives in this WebInspector.StylePropertyTreeElement.
Alexander Pavlov (apavlov)
Comment 4
2010-12-29 02:55:43 PST
Created
attachment 77610
[details]
[PATCH] propertyText change computation fixed
Pavel Feldman
Comment 5
2010-12-29 02:59:18 PST
Comment on
attachment 77610
[details]
[PATCH] propertyText change computation fixed View in context:
https://bugs.webkit.org/attachment.cgi?id=77610&action=review
> WebCore/inspector/front-end/CSSStyleModel.js:475 > + if (newProperty && this.disabled && !propertyText.match(/^\s*$/) && textChanged) {
No need to check for textChanged.
Alexander Pavlov (apavlov)
Comment 6
2010-12-29 03:54:41 PST
Landed with the nit fixed. Committing to
http://svn.webkit.org/repository/webkit/trunk
... M LayoutTests/ChangeLog A LayoutTests/inspector/styles-disable-then-change-expected.txt A LayoutTests/inspector/styles-disable-then-change.html M WebCore/ChangeLog M WebCore/inspector/front-end/CSSStyleModel.js Committed
r74740
Joseph Pecoraro
Comment 7
2011-01-10 22:40:32 PST
Comment on
attachment 77610
[details]
[PATCH] propertyText change computation fixed View in context:
https://bugs.webkit.org/attachment.cgi?id=77610&action=review
> WebCore/inspector/front-end/CSSStyleModel.js:477 > + return;
I have no objections to this patch, I was just curious why this branch early returns, and doesn't invoke the possible userCallback function like the other branches. I didn't investigate this deeply, but maybe that could use a comment?
Alexander Pavlov (apavlov)
Comment 8
2011-01-11 01:43:43 PST
(In reply to
comment #7
)
> (From update of
attachment 77610
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=77610&action=review
> > > WebCore/inspector/front-end/CSSStyleModel.js:477 > > + return; > > I have no objections to this patch, I was just curious why this branch early returns, > and doesn't invoke the possible userCallback function like the other branches. > I didn't investigate this deeply, but maybe that could use a comment?
Ugh, sorry for not commenting that, as it does looks strange to an untrained eye :) The point is that we need to run setPropertyText2+setDisabled(false) as an atomic operation, and hence the callback should be called only after setDisabled() returns (see enabledCallback()).
Joseph Pecoraro
Comment 9
2011-01-12 09:50:22 PST
> Ugh, sorry for not commenting that, as it does looks strange to an untrained eye :) > The point is that we need to run setPropertyText2+setDisabled(false) as an atomic > operation, and hence the callback should be called only after setDisabled() returns > (see enabledCallback()).
I see. That makes perfect sense, and its really my fault for overlooking that. Thanks!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug