Applying a bulk filter on accessibles in content process allows us to avoid a potentially large (and variable) number of IPC sync calls to retrieve the accessible names. I chose to implement this as a "post filter" and not to actually do the entire search in content because it would cause a lot of duplication of code for non-IPC searching, and we wouldn't have the flexibility to combine a text search with any arbitrary search key as the API requires.
I also generalized the RangeTypes.h header to PlatformExtTypes so it can be used to define filter types as well.
Differential Revision: https://phabricator.services.mozilla.com/D100730
Passing a union here allows us to reuse code and trim some code which was
duplicated to handle the different NodeId formats. This also consolidates the
former `NodeId` and `NodeIdData` structures into a new structure (working name
`NodeIdParts`) which represents parts that will later be converted to a string
based NodeId.
Differential Revision: https://phabricator.services.mozilla.com/D93569
We can now chaincreation of the decoder to the launch of the RDD process as needed and setting up the PRemoteDecoderManager
Differential Revision: https://phabricator.services.mozilla.com/D96365
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
We can now chaincreation of the decoder to the launch of the RDD process as needed and setting up the PRemoteDecoderManager
Differential Revision: https://phabricator.services.mozilla.com/D96365
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
In bug 1595994 we attempted to streamline the ability to determine which decoder was available regardless of the process they would be running in. This was subsequently done via the PDMFactory.
As there are several JS API that can query which codec are supported, it requires a synchronous mechanism.
This allowed to make a determination during the PlatformDecoderModule::Supports call, depending on which process it was going to be called frome.
Having a synchronous IPC call to the RemoteDecoderManagerParent has too many caveats to be workable.
So what we do instead is first determine at launch if the required external framework are available and pass this information to each content process.
When checking if a decoder is available, we make a best guess at determining if the PDM would support such codec, without actually loading such framework when running in the content process.
Supports can no longer make a decision based on the process currently running and as such PDM::CreateAudio/VideoDecoder using an optional system framework now need to further check the validity of the CreateDecoderParam argument.
Differential Revision: https://phabricator.services.mozilla.com/D95245
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
And we remove unnecessary checks, BackgroundParent only run in the parent process and if e10s is on. Also RecvLauchRDDProcess will only ever be called if the rdd pref is on already.
By streamlining the call we also reduce the number of sync dispatch to 1.
Depends on D93317
Differential Revision: https://phabricator.services.mozilla.com/D93476
Add a synchronous Supports message to the IPDL PRemoteDecoderManager protocol so
decoder modules can query for playback support in the actual process that will
attempt to do the decoding.
Depends on D54878
Differential Revision: https://phabricator.services.mozilla.com/D54879
The `clobber` targets are superseded by `mach clobber`, so we don't need them for any reason. The `clean` target is meant to get you to a post-`configure` state, but it doesn't really work, and if it's necessary for you to be in that state for some reason you can just clobber and re-`configure`, so it doesn't seem worth it to get it working again. Instead, delete all of them. Also delete `everything` which is not useful when `clobber` doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D93514
This patch does:
- Use LSWriteOptimizer
- Remove SessionStorageService since it's unused.
- Move IPC from PContent to PBackground
(by SessionStorageManager{Child, Parent} and SessionStorageCache{Child, Parent}).
- Extract SessionStorageManagerBase and add PBackgroundSessionStorageManager.
- Expose a getter function to get a BackgroundParentManager for top context id
on the parent.
IPC
- Before this patch:
- Copy from parent while loading a document.
- Mark cache entry on the parent process as loaded by the child id.
- Update change on checkpoint.
- Unmark cache entry on the parent process as unloaded for the child id while
the parent actor is destorying.
- After this patch:
- Sync IPC load in the first SessionStorage operation.
- Update change on checkpoint
`BackgroundSessionStorageManager`'s lifecycle on the parent process.
- Create by `SessionStorageManagerParent` and register to the `sManagers`.
- Hold by `SessionStorageManagerParent` and `sManagers`.
- Remove from the `sManagers` while the corresponding `BrowsingContext` is
destructed (on the parent process).
Depends on D89341
Differential Revision: https://phabricator.services.mozilla.com/D89342
There are at least 8 different methods for getting a range from an offset:
1. left word
2. right word
3. line
4. left line
5. right line
6. sentence
7. paragraph
8. range with same style.
Having a single wrapper and IPDL method for all of those with an enum would remove
a lot of redundancies.
Differential Revision: https://phabricator.services.mozilla.com/D90936
We use C++14's generic lambdas and its auto&& type in the generated code, in combination with a typed local variable to ensure the argument type is enforced.
The object is moved as necessary, no copies will occur.
The code generated will now be:
[this, self__, id__, seqno__](auto&& aParam) {
if ((!(self__))) {
NS_WARNING("Not resolving response because actor is dead.");
return;
}
bool resolve__ = true;
InitResultIPDL result = std::forward<decltype(aParam)>(aParam);
IPC::Message* reply__ = PRemoteDecoder::Reply_Decode(id__);
WriteIPDLParam(reply__, self__, resolve__);
// Sentinel = 'resolve__'
(reply__)->WriteSentinel(322044863);
WriteIPDLParam(reply__, self__, std::move(result));
// Sentinel = 'result'
(reply__)->WriteSentinel(153223840);
(reply__)->set_seqno(seqno__);
}
For multiple arguments return, creation of Tuple via Tie is also moved, though currently Tie method doesn't support move semantics.
Differential Revision: https://phabricator.services.mozilla.com/D90090
Doing this helps lower the chances of accidentally trying to send an
uninitialized primitive value, like a raw pointer or integer, over IPC due to a
sync method or IPDLParamTraits::Read implementation failing to initialize the
outparameter.
Differential Revision: https://phabricator.services.mozilla.com/D89963
We need a sync IPC call for this because otherwise the number of smaller sync messages we would need to call would be variable.
Differential Revision: https://phabricator.services.mozilla.com/D88076
This changes the duplicate checking/caching implemented by |parsed| to be
based on the name of the protocol etc. we're loading, not the file name.
This lets us detect when a protocol is being defined in two different
files.
This can happen if one file is included earlier in the resolve path than
a file explicitly specified on the command line. Any includes will resolve
to the former, and then we'll attempt to parse the latter. Before this
patch, this would result in weird errors, because there would be multiple
protocol types with the same name.
Differential Revision: https://phabricator.services.mozilla.com/D86113
This moves the IPC mechanism from PCompositorBridge to PLayerTransaction/
PWebRenderBridge, so that it can be used by content processes like the other
test APIs. It still only produces actual data for the layers backend; for
WR it will just return empty datasets.
Differential Revision: https://phabricator.services.mozilla.com/D86016
It could go into its own test suite, but it 1) depends on `mozbuild` code, so the `mozbuild` suite as well as this new suite would be running on any push that touches `mozbuild` code anyway, and 2) this is code that runs during the build, so it's not out of place.
Differential Revision: https://phabricator.services.mozilla.com/D84547
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
* Use clearer pref names.
* Default (and only support) IPDL dispatching.
* Make DispatchCommands async-only.
* Sync ipdl command per sync webgl entrypoint.
* Eat the boilerplate cost, since there's not too many.
* Run SerializedSize off same path as Serialize.
* All shmem uploads go through normal DispatchCommands.
* Defer pruning of dead code for now so we can iterate quickly.
* Use Read/Write(begin,end) instead of (begin,size).
* This would have prevented a bug where we read/wrote N*sizeof(T)*sizeof(T).
Differential Revision: https://phabricator.services.mozilla.com/D81495
The speedup here is not great because the Python/IPDL parser overhead is
very high, but this cuts ~10 seconds off a `-j12` build (~15s -> 4s) on
my machine.
Differential Revision: https://phabricator.services.mozilla.com/D81751
We move OnStartRequest from PHttpChannel to PHttpBackgroundChannel, thus adjusting
message-metadata.ini
Depends on D76970
Differential Revision: https://phabricator.services.mozilla.com/D76971
We move OnStartRequest from PHttpChannel to PHttpBackgroundChannel, thus adjusting
message-metadata.ini
Depends on D76970
Differential Revision: https://phabricator.services.mozilla.com/D76971
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
This method always copies, and is redundant with the other getter methods on
IPDL unions. As there is only one caller, it can be removed to simplify the
code, and remove a source of complexity.
Differential Revision: https://phabricator.services.mozilla.com/D75349
Fix intermittent issues due to races.
We now run the MozPromise generated by the IPDL bindings to run their callbacks via a direct task dispatch.
This avoids a full trip to the back of the event queue for each additional asynchronous step when using MozPromise.
A consequence to this change is that each IPDL actor's thread must have an AbstractThread allocated if IPDL MozPromises are used.
It prevents unexpected racy behaviours when combining MozPromise with the other Resolve/Reject IPDL async declaration which was have lead to processing the events out of order.
Differential Revision: https://phabricator.services.mozilla.com/D71593
The hashes of certain strings is used indirectly in generating IDL C++ files. Before, we were using the `hash()` function to generate these hashes, which in Python 3 is non-deterministic over subsequent `python3` processes, causing bugs like bug 1635755. Instead, use a specific, deterministic hash to avoid spurious diff failures.
The `md5` hash function isn't completely cryptographically secure but the security of the hashes isn't important for us in this case since we're just using them as a per-string identifier. We could use a more robust hash function but there may be performance implications from doing so.
Differential Revision: https://phabricator.services.mozilla.com/D74446
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
Adds IpdlQueue capability to PWebGL actors. The WebGLChild, used in content processes, implements SyncProducerActor and AsyncConsumerActor because it sends (sync and async) messages and receives responses to them that it reads as async messages. The WebGLParent, used in the compositor process, is a SyncConsumerActor and AsyncProducerActor for dual reasons.
Differential Revision: https://phabricator.services.mozilla.com/D68264
We need to separate WebGL actor construction and initialization since IpdlQueue initialization needs the actor to already exist.
Differential Revision: https://phabricator.services.mozilla.com/D68262
Adds IpdlQueue capability to PWebGL actors. The WebGLChild, used in content processes, implements SyncProducerActor and AsyncConsumerActor because it sends (sync and async) messages and receives responses to them that it reads as async messages. The WebGLParent, used in the compositor process, is a SyncConsumerActor and AsyncProducerActor for dual reasons.
Differential Revision: https://phabricator.services.mozilla.com/D68264
We need to separate WebGL actor construction and initialization since IpdlQueue initialization needs the actor to already exist.
Differential Revision: https://phabricator.services.mozilla.com/D68262
This commit:
- removes sendRpcMessage, which was unused;
- removes the CPOW argument to sendAsyncMessage, broadcastAsyncMessage, and
sendSyncMessage;
- removes the aIsSync argument used internally to distinguish sendRpcMessage
and sendSyncMessage;
- removes CPOW tests;
- updates the few remaining callsites that use more than 2 arguments in
sendAsyncMessage for the removal of the cpows argument.
Differential Revision: https://phabricator.services.mozilla.com/D71514
Before 1496578, URIFixup::keywordToURI used to do a synchronous IPC call to be
able to access search engines from the content process. Consumers of URIFixup
didn't care. Bug 1496578 moved the IPC messaging to the callers, in particular
nsDocShell, but assumed nsDocShellLoadState wasn't loading from content.
It looks like in some cases it does, so this adds another sync IPC call for
GetFixupURIInfo.
The total numer of sync IPCs should not change from before Bug 1496578, URIFIxup
was just doing it internally, while now it happens at the call point.
Note the long term plan would be for these docshell objects callers to just
handle URIs, while the UI code should do fixup.
Bug 1375244 tracks the removal of these sync IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D70607
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
This wasn't useful cross-platform.
ATK was the only consumer of this and it now uses ProxyAccessible::ChildAtPoint.
This also means the related aNeedsScreenCoords functionality in PDocAccessible::AccessibleAtPoint is no longer needed and has thus been removed.
Finally, this renames PDocAccessible::AccessibleAtPoint to PDocAccessible::ChildAtPoint for consistency with Accessible::ChildAtPoint now that the functionality is mirrored.
Differential Revision: https://phabricator.services.mozilla.com/D67987
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
Before this patch, PSM would register content type handlers to handle certain
certificate types. This was an easy way to install a client certificate after
generating a key with <keygen>, but keygen has been removed. This was also an
easy way to install root certificates, but that's actually a considerable
security risk. We kept this functionality for so long because it was the only
way to add a 3rd-party root certificate to Fennec's certificate store. Now that
Fennec is EOL, we can remove it. (Fenix will need a way to trust 3rd party root
certificates, but the path forward there is to implement the enterprise roots
feature for Android.)
Differential Revision: https://phabricator.services.mozilla.com/D66118
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
We were using the wrong Accessible method to get the level. We also need to swap IPDL methods to use the right one.
Differential Revision: https://phabricator.services.mozilla.com/D65645
--HG--
extra : moz-landing-system : lando
WalkHistoryEntries function gets called by nsSHistory::CloneAndReplaceChild
and nsSHistory::SetChildHistoryEntry recursively, so those have to be moved
into the parent process. This eliminates many sync IPC calls.
To facilitate transition to a new session history design,
we are mirroring mOSHE and mLSHE SH entries from docshell to browsing context.
Whenever we update those entries in docshell, we will also update those in BC,
and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D56201
--HG--
extra : moz-landing-system : lando
We want to be able to send IPC messages from the translation in the parent. So
the simplest thing it move the top level actor parts of CanvasParent into
CanvasTranslator.
This patch also moves the canvas thread management parts out into a new
CanvasThreadHolder class and hopefully makes the lifecycle management of these
much more robust. This includes the use of a TaskQueue per CanvasTranslator to
manage serial processing on the canvas workers, instead of a boolean.
Differential Revision: https://phabricator.services.mozilla.com/D60887
--HG--
rename : gfx/layers/ipc/CanvasParent.cpp => gfx/layers/ipc/CanvasThread.cpp
rename : gfx/layers/ipc/CanvasParent.h => gfx/layers/ipc/CanvasThread.h
rename : gfx/layers/CanvasTranslator.cpp => gfx/layers/ipc/CanvasTranslator.cpp
rename : gfx/layers/CanvasTranslator.h => gfx/layers/ipc/CanvasTranslator.h
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
The default method implementations cause problems when trying to
override them with different types in a direct call class.
For the `Recv__delete__` case there's a simple solution: omit it if
there are any arguments, because it doesn't make much sense to specify
arguments and then completely ignore them, and the no-arg case isn't a
problem for overriding.
Differential Revision: https://phabricator.services.mozilla.com/D62977
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
Replace all implicit copies by moves, or explicit clone operations.
Fixed a bug in /home/simon/work/ipdl/ipc/ipdl/ipdl/lower.py _cxxConstRefType,
which caused the const accessor to miss const on its return type for a moveonly
struct member.
Removed unused using directives for SerializedStructuredCloneBuffer in ipdl files.
Differential Revision: https://phabricator.services.mozilla.com/D59742
--HG--
extra : moz-landing-system : lando
Replace all implicit copies by moves, or explicit clone operations.
Fixed a bug in /home/simon/work/ipdl/ipc/ipdl/ipdl/lower.py _cxxConstRefType,
which caused the const accessor to miss const on its return type for a moveonly
struct member.
Removed unused using directives for SerializedStructuredCloneBuffer in ipdl files.
Differential Revision: https://phabricator.services.mozilla.com/D59742
--HG--
extra : moz-landing-system : lando
Splits WebGLContext into ClientWebGLContext and HostWebGLContext. The Client enables the JS-control of a WebGL context in a content procecss while the Host executes the WebGL graphics operations (via a WebGLContext that maintains much of the existing code) in the compositor process. At this point, the cross-process behavior is disabled -- this series of patches is an incremental step toward that final goal.
Differential Revision: https://phabricator.services.mozilla.com/D54018
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
Previously, we created TextureD3D11 objects in the content process to back surfaces created for the plugin process. Those objects were then composited by the async ImageBridge. In order to remove Win32 kernel operations from content (including DX/GDI operations), this patch bounces the requests from content to the compositor process. The compositor process maintains 2 textures to be used for all plugin composition -- one for the plugin process and one for display. The plugin process can freely write to its texture and request composition when it is done, which triggers a blit to the display texture. This mirrors pre-existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D46086
--HG--
extra : moz-landing-system : lando
These operations report whether certain async plugin drawing modes are supported on the host architecture. They use kernel graphics operations to decide this so they need to be removed from the content process for sandboxing. We just bounce the requests to the gpu process (or main process on systems without a GPU process).
Differential Revision: https://phabricator.services.mozilla.com/D46085
--HG--
extra : moz-landing-system : lando
`windowUtils.setCompositionRecording()` now returns a promise that is resolved
when the composition recorder is enabled (if given `true`) or when frames are
written to disk (if given `false`). To accomplish this, the
`WebRenderCompositionRecorder` now returns a `MozPromise` when writing frames
to disk begins that is resolved when that process finishes.
Differential Revision: https://phabricator.services.mozilla.com/D47300
--HG--
extra : moz-landing-system : lando
`windowUtils.setCompositionRecording()` now returns a promise that is resolved
when the composition recorder is enabled (if given `true`) or when frames are
written to disk (if given `false`). To accomplish this, the
`WebRenderCompositionRecorder` now returns a `MozPromise` when writing frames
to disk begins that is resolved when that process finishes.
Differential Revision: https://phabricator.services.mozilla.com/D47300
--HG--
extra : moz-landing-system : lando
Inside of nsDocShell::UpdateURLAndHistory, there are 4 sync IPC calls to
nsSHistory plus 1 static call, which contains at least one nsSHEntry::GetParent
sync IPC call. All of these calls can be moved inside of a new method
EvictContentViewersOrReplaceEntry on nsSHEntry, resulting in just 1 sync IPC
call.
Differential Revision: https://phabricator.services.mozilla.com/D32729
--HG--
extra : rebase_source : ad09a9061cd6fe8eb6796b2809ea191aceb3ac73
extra : source : 2cd5cd24763ff320719aedb2142a79822efd6de4
extra : histedit_source : fdc4f80cfd8807e46c2dc02e6ab82f2bd3acc391
Currently, nsDocShell::GetChildSHEntry calls 3 sync IPC calls on nsISHEntry,
and the method GetChildSHEntry only has one caller. By moving GetChildSHEntry
method to parent process for nsISHEntry, resulting in a new method
nsISHEntry::GetChildSHEntry, 3 sync IPC calls can be reduced to 1.
Differential Revision: https://phabricator.services.mozilla.com/D27633
--HG--
extra : rebase_source : 1e76a1b07d827b35bae7ed6acca25aa8732c9ed0
extra : source : 34d91f82faa36dd8d8ed721de365122d831f7b25
extra : histedit_source : 86592bc747d506c546ec660e57087e78b9719cf7
Inside of nsDocShell::OnNewURI there are 4 sync IPC calls
to nsSHistory that can be replaced with 1 sync IPC call
by adding a new method EnsureCorrectEntryAtCurrIndex to nsSHistory.
Differential Revision: https://phabricator.services.mozilla.com/D31539
--HG--
extra : rebase_source : 09d7738b2f2dc2334c8f6186e5918b9d0ea3e618
extra : source : 82a41bffcbbca24ad3e84b045d75e4cb01ae1445
extra : histedit_source : 96eb7d2dbed2ad8fe4cc2d37358ec2358f696442
In nsDocShell::LoadHistoryEntry method, when it gets called
from parent process, there are 13 sync IPC calls on nsISHEntry
that retrieve information from the session history entry and
create a doc shell load state object using the retrieved
information. By adding a new method 'CreateLoadInfo'on nsISHEntry,
inside of which the doc shell load state object will be
created (with appropriate data filled out) and returned,
we eliminate 12 sync IPC call, resulting in just 1 IPC call
to nsISHEntry::CreateLoadInfo.
Differential Revision: https://phabricator.services.mozilla.com/D26042
--HG--
extra : rebase_source : a4e1fa52932fd5caabb59bd133e9fbee7f4d0e4a
extra : amend_source : f4d9f01afac0337808ba347eb997ce83e6ae1488
extra : source : 6ad53b35c7b4be933a3db1e1d45fa3da8a57abad
extra : histedit_source : c08d0cebcc11a3a4f64d01566cb62d9a334a12ec
Currently, nsDocShell repeatedly calls nsISHEntry::GetChildAt and
nsISHEntry::RemoveChild in nsDocShell::AddToSessionHistory,
which results in twice as many IPC calls as the number of children
a session history entry has. Additionally, there is one extra
IPC sync call to nsISHEntry::AbandonBFCacheEntry after the loop.
With the proposed solution, there will only be 1 sync IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D24978
--HG--
extra : rebase_source : ab98af417bcb28fdfcb1a115473b505fa8a70aa1
extra : source : 0270d6b952ffa1704690c777c55fcaed30125b38
extra : histedit_source : 9a031cb921ad8efa1bd96f7342e08337f3c0ca8a
Currently, nsDocShell repeatedly calls nsISHEntry::GetChildAt, which
results in as many IPC sync calls as the number of children
a session history entry has. Calling nsISHEntry::GetChildCount and
ChildSHistory::Index and incurs additional extra 2 sync IPC calls.
With the proposed solution, there will only be 1 sync IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D24980
--HG--
extra : rebase_source : ffaaff5c9521fb4d3a53a85f4570bcb99f7317d1
extra : source : 3f4a092d8f6544a212ee8a80d9275ae68c6446d1
extra : histedit_source : b4166d997119092ba5657f9ca4216da62dc82d97
This takes the approach of directly tying the `AddRef()` and `Release()` calls
on the underlying actor object to the lifecycle of the ActorLifecycleProxy
object, by adding another virtual `ActorAlloc()` method as the counterpart to
`ActorDealloc()`.
The changes to the methods called from C++ are relatively minimal:
1. The `SendPFooConstructor(...)` methods have the same signature, but now will
AddRef() internally (through `ActorAlloc()`), so an `do_AddRef(foo).take()`
isn't needed. Same with the `{Bind,Open}PFooEndpoint` methods.
This was done to reduce the number of invasive internal changes in the
codegen which were required to pipe a passed-in `already_AddRefed` to the
underlying `ActorLifecycleProxy` which is created by generic code.
2. The `AllocPFoo{Parent,Child}` methods have been modified to return an
`already_AddRefed` by default, and the callsites will store the result in a
`RefPtr<T>` if the type is refcounted.
3. No `DeallocPFoo...` method is called anymore. Unfortunately due to
devirtualization, it won't be an error if an unused method is still present,
though it won't be called.
Differential Revision: https://phabricator.services.mozilla.com/D39502
--HG--
extra : moz-landing-system : lando
The syntax for the new construct looks like the following, and re-uses the
refcounted keyword from refcounted using statements:
async refcounted protocol PFoo { ... }
Differential Revision: https://phabricator.services.mozilla.com/D39501
--HG--
extra : moz-landing-system : lando
The previous behaviour of failing unconditionally was performed as, during
shutdown, the channel could become unable to send without worker threads having
a chance to react. This change keeps that behaviour, isolating async message
senders from impending IPC shutdown, while performing expected actor teardown if
the manager actor has already been destroyed, and should no longer send messages.
An alternate behaviour here could be to crash if !Manager()->CanSend(). That
behaviour may be preferable if a sufficient number of callsites don't check the
return value of the `SendPFooConstructor()` method.
Differential Revision: https://phabricator.services.mozilla.com/D39534
--HG--
extra : moz-landing-system : lando
The vast majority of the virtual methods which were used on ProtocolState were
actually methods which only had meaningful implementations on the toplevel
protocol. This patch adds a new field to IProtocol holding a direct pointer to
the protocol's `IToplevelProtocol`, and the methods formerly implemented with
ProtocolState now directly call the corresponding method on IToplevelProtocol.
IToplevelProtocol then shadows these methods with the toplevel protocol
implementation, meaning that the right code is run in the right places.
In addition, some state was maintained for protocols inside of the separate
ProtocolState allocation, and this patch moves that state back into the actor
itself.
Differential Revision: https://phabricator.services.mozilla.com/D32044
--HG--
extra : moz-landing-system : lando
Make nsIWebBrowserPrint included unconditionally for addressing nsIDocShell.rs build failure.
Remove direct_call of PPrinting and PRemotePrintJob. Their ipdl are built unconditionally, but their derived classes are not built with --disable-printing.
Differential Revision: https://phabricator.services.mozilla.com/D33391
--HG--
extra : moz-landing-system : lando
This allows for the getter to be used in IProtocol's destructor, and generally
brings IProtocol more in line with IToplevelProtocol.
Differential Revision: https://phabricator.services.mozilla.com/D32042
--HG--
extra : moz-landing-system : lando
These values were only being used for assertions within IPDL send
methods. They had no positive impact beyond causing crashes when sending
a message over a dead actor.
Differential Revision: https://phabricator.services.mozilla.com/D30235
--HG--
extra : moz-landing-system : lando
Historically we've failed very loudly when receiving a message which was
destined for an actor which had already been destroyed. This had the
effect of requiring manual teardown for most actors, as work would need
to be done to ensure messages weren't sent when the target actor might
be about to tear itself down.
In addition, due to this teardown work being done outside of IPDL, this
work would have to manually be checked in subactors, and involved the
addition of new flags, such as `mIPCOpen`, in order to track whether IPC
had begun to be shut down, and discard messages manually if it had.
It is an ongoing issue that we occasionally miss places where we need to
discard messages, and it is easy to not remember to perform async
destruction when building a new actor, meaning that extra work is
required to correctly discard messages when the actor is being torn
down. Due to the correct decision, almost all of the time, being to
discard the message, this patch takes the approach of transforming the
crash which was previously performed into a message discard.
The hope is that this will reduce the burden on actor implementors, by
allowing the use of `Send__delete__` without first synchronizing with
the remote actor, as well as reduce unintentional crashes.
Differential Revision: https://phabricator.services.mozilla.com/D28892
--HG--
extra : moz-landing-system : lando
This patch changes the way how we handle sync ctor send errors. They are now
ignored and treated like messages which successfully were queued to send, but
got lost due to the other side hanging up.
For more details, see bug 1509362 which originally did it for async ctors.
The main differences here are that we destroy the actor and we return null when
the send fails.
Differential Revision: https://phabricator.services.mozilla.com/D31517
This isn't needed now that BrowserParent has the same name
as the protocol.
Differential Revision: https://phabricator.services.mozilla.com/D30151
--HG--
extra : rebase_source : dbfc1722a43e1f8fbbe01f1766a397b570fa7d6a
extra : source : 792b49f269bb6308e152290ed0dfa03efbffa536
extra : histedit_source : e001669549af547f5387a3b010ad52ebee6eea3f
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
This consolidates array, maybe and unique ptrs in IPDL into a single
"has base type" qualifier, for types that wrap another type. I'm not
sure this patch fixes everything, but I think it is at least more
correct.
It also adds checking for the stuff inside the UniquePtr<>, because
the intent seems to be to allow things like protocol types in there.
Differential Revision: https://phabricator.services.mozilla.com/D28571
--HG--
extra : moz-landing-system : lando
Currently, when deserialization fails, the error message contains the base
name of the C++ type, without template parameters; this means we can get
unhelpfully vague errors about `RefPtr` or `Maybe` or `nsTArray`. (The
identical error cases are then merged by the compiler, so the execution
path can't be recovered from the crash dump.)
This patch uses the IPDL type instead. It would be possible to invoke
the code generator to use the full C++ type, but more complicated for no
real benefit.
Differential Revision: https://phabricator.services.mozilla.com/D28401
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
PPluginInstance's __delete__ was ported from rpc to intr, and is the
only non-async IPDL deletion in the codebase. We should be able to
align this with the rest of the IPDL interfaces and remove the need
for specialized intr __delete__ handling.
Differential Revision: https://phabricator.services.mozilla.com/D25674
--HG--
extra : moz-landing-system : lando
Add a new nsExternalHelperAppService derived class named nsOSHelperAppServiceChild to be used for the MIME service, external helper app service, and external protocol service interfaces in child processes. nsOSHelperAppServiceChild overrides some methods used to get MIME and external protocol handler information from the OS and implements these methods by remoting the calls to the parent process.
This is necessary because, on Mac, querying the OS for helper application info from sandboxed content processes is unreliable and has buggy side effects.
For now, only use the new class on Mac.
Android and unix file changes r+ by gcp.
Windows files changes r+ by bobowen.
Sync messages review r+ by nfroyd.
MozReview-Commit-ID: 63BiS6VCxfn
Differential Revision: https://phabricator.services.mozilla.com/D15620
--HG--
extra : moz-landing-system : lando
Add a new nsExternalHelperAppService derived class named nsOSHelperAppServiceChild to be used for the MIME service, external helper app service, and external protocol service interfaces in child processes. nsOSHelperAppServiceChild overrides some methods used to get MIME and external protocol handler information from the OS and implements these methods by remoting the calls to the parent process.
This is necessary because, on Mac, querying the OS for helper application info from sandboxed content processes is unreliable and has buggy side effects.
For now, only use the new class on Mac.
Android and unix file changes r+ by gcp.
Windows files changes r+ by bobowen.
Sync messages review r+ by nfroyd.
MozReview-Commit-ID: 63BiS6VCxfn
Differential Revision: https://phabricator.services.mozilla.com/D15620
--HG--
extra : moz-landing-system : lando
Now that fields are packed nicely, we can take advantage of the
contiguous layout of POD fields and read/write all the POD fields of a
given size in a single read/write call. For many structs, this should
have little or no effect, but for large structs such as LoadInfoArgs,
this reduces the number of function calls by ~50%.
Differential Revision: https://phabricator.services.mozilla.com/D22001
--HG--
extra : moz-landing-system : lando
We're about to start depending on how the fields are packed in a future
patch, so we should add some compile-time checking that our assertions
are correct.
Differential Revision: https://phabricator.services.mozilla.com/D22000
--HG--
extra : moz-landing-system : lando
We're going to read and write sentinels slightly differently for
bulk-writing adjacent fields, so let's factor out some reusable code for
doing so.
Differential Revision: https://phabricator.services.mozilla.com/D21999
--HG--
extra : moz-landing-system : lando
This patch changes the layout of IPDL-defined structs to order the POD
members by decreasing size, which ensures everything is packed well.
This optimization is only applied to the internal representation; the
external interface (e.g. constructors) is entirely unchaged.
Differential Revision: https://phabricator.services.mozilla.com/D21998
--HG--
extra : moz-landing-system : lando
This patch computes an ordering for the fields of an IPDL structure decl
such that they are packed well in memory. We'll take advantage of this
ordering in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D21997
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This follows the naming convention of the related functions _splitClassDeclDefn() and _splitFuncDeclDefn().
Depends on D20056
Differential Revision: https://phabricator.services.mozilla.com/D20057
--HG--
extra : moz-landing-system : lando
Bug 1428984 caused a regression where ipdlc will emit (empty) method definitions for pure methods. C++ allows a pure member function to have a definition (in case a derived class wants to call a default implementation in the base class), but we don't want this for ipdl's generated code.
Differential Revision: https://phabricator.services.mozilla.com/D20056
--HG--
extra : moz-landing-system : lando
nsSystemInfo is initialzied at first page load. Actually, content process uses
sync IPC to get Android OS information. But now, we can use Java code even if
on content process, so we should use JNI directly instead of sync IPC.
Also, nsSystemInfo still has unused extern android_sdk_version that is for
HoneyComp's DNS hack. So let's remote it.
Differential Revision: https://phabricator.services.mozilla.com/D20129
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
The one exception is refcounted types, because std::move(RefPtr<T>) does not
coerce to T*, which is what the current IPC methods accept.
This does not rewrite all Recv/Answer methods to take advantage of move
semantics.
Differential Revision: https://phabricator.services.mozilla.com/D19669
--HG--
extra : moz-landing-system : lando
This removes all .flake8 files except for the one at the root of the repo.
Instead we use the new 'per-file-ignores' config introduced in 3.7. To ignore
specific errors in a subdirectory, add a line like this to the root .flake8:
[per-file-ignores]
path/to/subdir/*: E100, F200, ...
The reasons for this change are:
1. Unblock flake8 blacklist (bug 1367092).
2. Simplify configuration and code.
3. Encourage more consistent styling.
4. Improve performance.
5. Greater editor consistency.
Differential Revision: https://phabricator.services.mozilla.com/D18354
--HG--
extra : moz-landing-system : lando
This bumps flake8 to version 3.7.5.
This also ignores the new lint rules that were added in the new versions.
These rules are de-marked via comment so we know that they should be enabled at
some point (as opposed to the other rules that are (presumably) ignored
intentionally.
Differential Revision: https://phabricator.services.mozilla.com/D18353
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
In order to enable asynchronous launch, destruction of
GeckoChildProcessHost (and its subclasses) has to be delayed until after
launching (or anything else that might be made asynchronous in the
future) has completed, to prevent use-after-free. However, there are
other dependencies on process hosts always being destroyed on the I/O
thread, so refcounting would be difficult to use.
Instead, GeckoChildProcessHost now may not be destroyed directly, but
must go through a method that handles the scheduling.
There are also some minor cleanups to the affected headers (removed
duplicate access modifiers, and made PluginProcessParent final).
Depends on D18010
Differential Revision: https://phabricator.services.mozilla.com/D18011
--HG--
extra : moz-landing-system : lando
This file has text-substitution placeholders that aren't part of normal
C++ syntax; they were broken by auto-inserted whitespace. This patch
restores the original formatting and protects them from further change.
Differential Revision: https://phabricator.services.mozilla.com/D18010
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
David Parks
Simon Giesecke
Csoregi Natalia
Tom Ritter
Noemi Erli
Cosmin Sabou
Nika Layzell
Mike Hommey
Florian Quèze
M. Sirringhaus
Andreea Pavel
Eitan Isaacson
Masayuki Nakano
Bryce Seager van Dyk
Jean-Yves Avenard
Bogdan Tara
Brindusan Cristian
Ricky Stewart
Andrew Osmond
Dorel Luca
Dan Glastonbury
Tom Tung
Mark Banner
Andrew McCreight
Kartikaya Gupta
Emilio Cobos Álvarez
Jeff Gilbert
Tom Prince
Nathan Froyd
Junior Hsu
Butkovits Atila
Gijs Kruitbosch
Peter Van der Beken
Daniel Varga
Kershaw Chang
Makoto Kato
Chris Peterson
Marco Bonardo
Chris Martin
James Teh
Razvan Maries
Sylvestre Ledru
Mihai Alexandru Michis
Dana Keeler
Anny Gakhokidze
Jonathan Kew
Ciure Andrei
Bob Owen
Jed Davis
Oana Pop Rus
David Parks
Olli Pettay
Gabriele Svelto
Barret Rennie
Jim Porter
Aaron Klotz
Byron Campen [:bwc]
Andrea Marchesini
Jonathan Kingston
Matt Woodrow
sotaro
Jan Varga
Ryan Hunt
Bas Schouten
Kyle Machulis
Alex Gaynor
Haik Aftandilian
arthur.iakab
Chris Pearce
Nathan Froyd
Boris Zbarsky
Michael Froman
Andrew Halberstadt
Greg Tatum
Ehsan Akhgari