Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How about adding "^" to static filter made from logger? #2740

yasmise opened this issue Jun 27, 2017 · 2 comments


Copy link

commented Jun 27, 2017

Describe the issue

When I create a static filter from logger, I sometimes insert a "^" to the created filter if that doesn't end with specific file name. Please see this image.


In this case, I'm making a filter to block javascripts under, however, generated filter is ||$script,, so, this filter could be overkill if they have javascripts under or something.
I would really appreciate it if you could add "^" to the generated filter, like ||^$script,

One or more specific URLs where the issue occurs

You can use any web pages because this is a user interface issue.

Screenshot in which the issue can be seen

Please see above.

Steps for anyone to reproduce the issue

  1. Visit a web page (e.g.
  2. Open logger of uBlock origin and reload the page to make log.
  3. Click 4th column of logger to make a static filter (e.g. row of script:
  4. Select Static filtering tab, change matching URL to a URL which doesn't contain specific file name (e.g. change to
  5. The generated filter doesn't have "^" before "$".

Your settings

  • OS/version: Windows 10 Home 1703
  • Browser/version: Firefox 54.0
  • uBlock Origin version: 1.13.0
Your filter lists

My filter
uBlock filters
uBlock filters - Badware risks
uBlock filters - Privacy
uBlock filters - Unbreak
Malware Domain List
Malware domains
Fanboy's Annoyance List
Peter Lowe’s Ad and tracking server list
Adguard Japanese filter (
Spyware filter (
Tofu filter (

Your custom filters (if any)


@gorhill gorhill added the accepted label Jun 27, 2017


This comment has been minimized.

Copy link

commented Jun 27, 2017

How about instead of ^, I just keep the / character that is already in there (i.e. || The problem with using ^ with your scenario is that it forces the filter to be regex-based internally, i.e. inefficient. Using / means the engine can still use plain string comparison internally.

The ^ could still be used for plain hostname matching though (it's a special case internally, i.e. ||^)


This comment has been minimized.

Copy link

commented Jun 28, 2017

Yes, I agree with you. I'm for to keep /, instead of ^.
Thanks for your quick reply and kind description.

@gorhill gorhill closed this in 2cb8ddb Jul 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.