Issue 29329521: Issue 3222 - Expose filter type as a string property

Keyboard Shortcuts

	File
u :	up to issue
m :	publish + mail comments
M :	edit review message
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line
<Enter> :	respond to / edit current comment
d :	mark current comment as done

	Issue
u :	up to list of issues
m :	publish + mail comments
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue
# :	close issue

	Comment/message editing
<Ctrl> + s or <Ctrl> + Enter :	save comment
<Esc> :	cancel edit

Issue 29329521: Issue 3222 - Expose filter type as a string property (Closed)

Created:
Oct. 29, 2015, 7:41 p.m. by Wladimir Palant

Modified:
Nov. 11, 2015, 2:11 p.m.

Reviewers:
Thomas Greiner, tschuster

Visibility:
Public.

Description

Issue 3222 - Expose filter type as a string property

Patch Set 1 #

Total comments: 2

Created: Oct. 29, 2015, 7:41 p.m.

Download [raw] [tar.bz2]

	Unified diffs	Side-by-side diffs	Stats (+38 lines, -25 lines)			Patch
M	chrome/content/ui/filters-filterview.js	View	2 chunks	+2 lines, -14 lines	0 comments	Download
M	chrome/skin/filters.css	View	1 chunk	+5 lines, -3 lines	0 comments	Download
M	lib/filterClasses.js	View	8 chunks	+26 lines, -3 lines	0 comments	Download
M	lib/requestNotifier.js	View	2 chunks	+5 lines, -5 lines	2 comments	Download

Messages

Total messages: 4

Expand All Messages | Collapse All Messages

Thomas Greiner

LGTM Feel free to either reject the proposed approach or otherwise implement it in a ...

Nov. 3, 2015, 11:32 a.m. (2015-11-03 11:32:40 UTC) #3

Wladimir Palant

Nov. 3, 2015, 12:23 p.m. (2015-11-03 12:23:25 UTC) #4

https://codereview.adblockplus.org/29329521/diff/29329522/lib/requestNotifier.js
File lib/requestNotifier.js (right):

https://codereview.adblockplus.org/29329521/diff/29329522/lib/requestNotifier...
lib/requestNotifier.js:217: if (filterType != "elemhide" && filterType !=
"elemhideexception" && filterType != "cssproperty")
On 2015/11/03 11:32:40, Thomas Greiner wrote:
> Just a suggestion: What about introducing an `isException` boolean property in
> addition to the `type` property you introduced. That'd allow us to have a
common
> type for ElemHideFilter and ElemHideException that we can check for - similar
to
> how we currently check for ElemHideBase.
> 
> That'd allow us to keep checking filter inheritance at least to some extent
> without introducing too much overhead.

I think that would complicate things more than it would help. Right now there is
a 1:1 mapping between types and type strings, that's very straightforward. If
the type structure gets any more complicated we might want to think about type
identifiers like "elemhide:exception" and "elemhide:cssproperty" but I don't
think we are at a point where this would make sense.

Expand All Messages | Collapse All Messages