LookupCacheV4::Has implements safebrowsing v4 caching logic.
1. Check if fullhash match any prefix in local database:
- If not, the URL is safe.
2. Check if prefix is in the cache(prefix is always the first 4-byte of
the fullhash, Bug 1323953):
- If not, send fullhash request
3. Check if fullhash is in the positive cache:
- If fullhash is found and it is not expired, the URL is not safe.
- If fullhash is found and it is expired, send fullhash request.
4. If fullhash is not found, check negative cache expired time:
- If negative cache time is not expired, the URL is safe.
- If negative cache time is expired, send fullhash request.
MozReview-Commit-ID: GRX7CP8ig49
--HG--
extra : rebase_source : bcb5fa7aa2b7b116d862e3382447611424603c2d
This patch includes following changes:
1. nsUrlClassifierHashCompleter.js
nsUrlClassifierHashCompleter.idl
- Add completionV4 interface for hashCompleter to pass response data to
DB service.
- Process response data includes negative cache duration, matched full
hashes and cache duration for each match. Full matches are passed through
nsIFullHashMatch interface.
- Change _requests.responses from array contains matched fullhashes to
dictionary so that it can store additional information likes negative cache
duration.
2. nsUrlClassifierDBService.cpp
- Implement CompletionV4 interface, store response data to CacheResultV4
object. Expired duration to expired time is handled here.
- Add CacheResultToTableUpdate function to convert V2 & V4 cache result
to TableUpdate object.
3. LookupCache.h
- Extend CacheResult to CacheResultV2 and CacheResultV4 so we can store
response data in CompletionV2 and CompletionV4.
4. HashStore.h
- Add API and member variable in TableUpdateV4 to store response data.
TableUpdate object is used by DB service to pass update data or gethash
response to Classifier, so we need to extend TableUpdateV4 to be able
to store fullHashes.find response.
6. Entry.h
- Define the structure about how we cache fullHashes.find response.
MozReview-Commit-ID: KgR1NASl7GC
--HG--
extra : rebase_source : 424db14e4af2ffd691c384414d50f64083d5d20b
This patch fixes that Classifier::ActiveTables doesn't return v4 tables.
Classifier::mActiveTablesCache is generated by scanning safebrowsing directory.
We use Classifier::ScanStoreDir to do the work, but it will ignore subdirectory.
Since v4 tables are stored in subdirectory 'google4', mActiveTablesCache doesn't
include v4 tables.
Fix this issue by checking subdirectory recursively in ScanStoreDir.
MozReview-Commit-ID: I6pa6e4bFND
--HG--
extra : rebase_source : 49d19101bec780e21db668b2daff3c46bbdb3fd2
Recently, [@]froydnj had some trouble with `mach`, and after half an hour of struggle, a simple `git clean` and `git reset --hard` seemed to fix the issue. Apparently, sometimes (though I'm not sure when, and I don't even have a convincing argument), the changes to `mach` scripts don't really seem to reflect on the related bytecode files (when it absolutely should've!).
Having bytecode files is just a matter of optimization (i.e., we don't have to compile the scripts again), but when it comes to our simple build system, "not having them" doesn't add a great overhead. So, we could just disable their creation to avoid such issues in the future.
Existing users can do `find ./python -name '*.pyc' -delete` for a cleanup (and maybe remove the `python/_virtualenv` directory too, though not necessary)
Source-Repo: https://github.com/servo/servo
Source-Revision: ca3cd64d6b1999292d634bfa237c2705e6d575c1
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f14d2e622061e164ccc9f02b60a226c41d881629
<!-- Please describe your changes on the following line: -->
When computing the inline size of an inline block in inline formating
context, use the margin box of the underling block.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#12413 (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 4013e9d7a0be666343ef9d806408af5c0a852d91
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a3e0b41862e06b9bc419207ea74be4ba5edcaa11
This was meant to be temporary, and we can remove it now.
MozReview-Commit-ID: 2A9RKIabYIZ
--HG--
extra : source : e6cd7e39bfdd77772ffd3a36448b7763db7ec6d1
extra : histedit_source : dcb1bd9d144aaa9abeef38107a6ee6d85cdf7b2f
There might be up to 2 Always-show-as-action button in ActionBar.
One for menu-options, one for 3rd-party app action-button, if any.
According to our design spec, the two buttons appearance should be
similiar, therefore now we create them by same method.
MozReview-Commit-ID: GPVteQR3hxr
--HG--
extra : rebase_source : f03b2dcda5864221abe301d1b1ce8f8c1c38752d
The inspector's DocumentWalker had several issues when trying to retrieve
children for a given node, especially if the starting node was filtered
out by the filter function of the walker.
If the starting node was provided by options.center or options.start
and if this starting node was filtered out by the walker's filter
then the walker would fallback to the first valid parent of this node.
eg with
parent1 > parent2 > [valid-node, invalid-node, valid-node]
When asking for the children of parent2, if the walker started on
"invalid-node", then the walker would instead use parent2 and in turn
we would retrieve the children of parent 1
To fix that we can either tell the walker wether it should fallback to a
sibling of the starting node or to a parent, or make sure that the nodes
provided to the walker are valid.
A second issue was with the utility methods _readForward and _readBackward.
They both use the next/previousSibling() methods of a walker in order to
collect all the valid siblings of the walker's current node. But they were
always including the current node of the walker in their return array. And
there is no guarantee that the walker's currentNode is actually valid for it's
filter.
eg with a walker containing [invalid-node-1, invalid-node-2, valid-node].
Let's say the walker is currently on valid-node and we call previousSibling
The walker will do 3 steps:
- this.walker.previousSibling() > returns invalid-node-2, fails filtering
- this.walker.previousSibling() > returns invalid-node-1, fails filtering
- this.walker.previousSibling() > returns null, stop looping and return null
But at this stage the internal walker still points to the last visited node
(invalid-node-1). So if _readForward/Backward blindly add the current node
of the walker, we might be returning invalid nodes.
MozReview-Commit-ID: 72Be7DP5ky6
--HG--
extra : rebase_source : 31e7d3321abef04243b741196d4ca6279cefd53a
The cctools-port build scripts were pulling and building the master branch
of the cctools-port repo, which means they'd build whatever was there
when they get triggered. I think this was copied from my build-cctools
script which did the same thing, so it's my fault in the end! This patch
pins a revision in the script so we'll build the same thing until we
explicitly update.
I also fixed the scripts to use git instead of tc-vcs, since tc-vcs prints
misleading error messages, and nothing else uses that anymore.
Finally, I removed the build-cctools script, since all the builds are using
cctools-port now so it doesn't serve any useful purpose.
MozReview-Commit-ID: 5myqHS4duor
--HG--
extra : rebase_source : 11231cbe49c7ba830a880bfa4600f0a24d61471d
The newer Theming API follows the WebExtension install flow, which uses
PopupNotifications to request permission before installation, show progress and
notify upon install completion. This patch makes sure that older LWTs follow that
same flow.
MozReview-Commit-ID: C7X2si0a47J
--HG--
extra : rebase_source : 76f6283818dd69f62c4d59b6b11c5e90d37145a2
Put back in line that was incorrectly removed previously, and add a test.
MozReview-Commit-ID: FEl8fT1uCDm
--HG--
extra : rebase_source : 549b4d9ab9c963ab5a92b81311cffe07fae6953c
