summaryrefslogtreecommitdiff
path: root/ipc
Commit message (Collapse)AuthorAge
* Issue #25 - Part 18: Remove GMP (or nearly all of it)Matt A. Tobin2022-04-21
| | | | I had planned to ifdef GMP but the infection is so deep that I couldn't do discrete parts and have it stay building.
* Issue #25 - Part 17: Remove XREChildDataMatt A. Tobin2022-04-21
|
* Issue #1 - Restore Gecko Media PluginsMatt A. Tobin2022-04-20
|
* Revert "Issue %3015 - Part 2: Remove XREChildData."Matt A. Tobin2022-04-20
| | | | This reverts commit bca6f8a4592bb03a25b8228392e5e2b58a39cc82.
* Revert "Issue %3057 - Part 9: Adjust all callsites for no longer using ↵Matt A. Tobin2022-04-09
| | | | | | GetNativePath" This reverts commit 097fa969802f76530384926e8ef1f56777be3783.
* Issue %3060 - Resolve remaining RELEASE_OR_BETA conditionals.Moonchild2022-02-04
|
* Issue %3057 - Part 9: Adjust all callsites for no longer using GetNativePathMoonchild2022-02-03
| | | | Depending on context, various solutions were used.
* Issue %3015 - Part 2: Remove XREChildData.Moonchild2022-01-02
| | | | | | Since we no longer have to deal with passing arbitrary data structures to plugins when not dealing with GMP/EME/CDMs (for auth keys and what not), this is no longer needed.
* Issue %3015 - Part 1: Remove GMP support code.Moonchild2022-01-02
|
* Issue %1314 - Part 16: Remove WebRTC remainders.Moonchild2021-12-25
| | | | | Stuff still left in the tree directly mentioning WebRTC are comments or copyright notices, primarily.
* Issue %1314 - Part 14: Misc fixesMoonchild2021-12-07
| | | | | | | - Remove WEBRTC_{WIN|POSIX} - Remove more PeerIdentity methods - Remove int32_t versions of LatencyLog - Move WebCrypto GenerateAsymmetricKeyTask back to where it belongs.
* Issue %3014 - Part 8: Fix build issues after removal of /media/webrtcMoonchild2021-11-28
|
* Issue %3014 - Part 1: Remove conditional WebRTC codeMoonchild2021-11-26
|
* Issue %3005 - Centralize the Security Features and locate them to ↵Matt A. Tobin2021-11-23
| | | | system/security
* Issue %3005 - Move toolkit/xre to system/runtimeMatt A. Tobin2021-11-22
|
* No Issue - Clean-up stray right parenthesis and remove a Mac define.Jeremy Andrews2021-10-23
|
* Issue %3020 - Part 9: Second pass remove android defines and build system stuff.Moonchild2021-10-17
| | | | Mostly IPC, tools and mozbuild.
* Issue %3020 - Part 3: Remove /dom/system/android and dependent modules, as wellMoonchild2021-10-14
| | | | as robocop.
* No issue - Clean up some obsolete/archaic code paths.Moonchild2021-09-30
|
* Issue mcp-graveyard/UXP%1751 - Nuke MOZ_WIDGET_COCOAMoonchild2021-09-29
|
* Issue mcp-graveyard/UXP%1751 - Nuke remaining macbuild considerations from GREMoonchild2021-09-29
|
* Issue mcp-graveyard/UXP%1751 -- Remove XP_MACOSX conditionals from the rest ↵Moonchild2021-05-06
| | | | | | | of the tree. This also removes some PP abuse and takes file entries out of PP when no longer needed without XP_MACOSX conditionals.
* Issue mcp-graveyard/UXP%1751 -- Remove files unused without XP_DARWINMoonchild2021-05-02
|
* Issue mcp-graveyard/UXP%1751 -- Remove XP_DARWINMoonchild2021-05-02
|
* Issue mcp-graveyard/UXP%1751 -- Remove XP_IOSMoonchild2021-05-01
|
* Issue mcp-graveyard/UXP%1699 - Part 2: libevent: Remove ↵Olivier Certner2021-01-07
| | | | | | | | | | | | | | | | | | | | | 'evutil_secure_rng_add_bytes' In fact, this is a security threat. This function calls 'arc4random_addrandom', which was removed from the reference implementation 7 years go [1], on the ground that this was in fact an internal interface which is almost impossible to use correctly. This update has since then been propagated to other implementations (e.g., FreeBSD, IllumOS, Android). Do this for all platforms, since 'evutil_secure_rng_add_bytes' is not even used in the current tree, and for the reason stated above, should never be. Related bugs at Mozilla and libevent: Links [2] and [3] below. [1] http://marc.info/?l=openbsd-cvs&m=138238762705209&w=2 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=931354 [3] https://sourceforge.net/p/levent/bugs/320/
* Issue mcp-graveyard/UXP%1606 - Add support for multi-monitor DPI awareness ↵Moonchild2020-10-06
| | | | v2 (W10 1706+)
* Issue mcp-graveyard/UXP%1656 - Fix broken comment from Part 1Gaming4JC2020-09-26
| | | | Removing the vim line unintentionally broke the comment leading to build failure, this restores the comment.
* Issue mcp-graveyard/UXP%1656 - Part 8: Devtools and misc.Moonchild2020-09-24
|
* Issue mcp-graveyard/UXP%1656 - Part 6: Clean up the build filesMoonchild2020-09-23
|
* Issue mcp-graveyard/UXP%1656 - Part 4: Tackle *.idl, *.css, *.ipdlh, ↵Moonchild2020-09-23
| | | | *.webidl, *.cc
* Issue mcp-graveyard/UXP%1656 - Part 1: Nuke most vim config lines in the tree.Moonchild2020-09-23
| | | | | | Since these are just interpreted comments, there's 0 impact on actual code. This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are a few others scattered around which will be removed manually in a second part.
* Bug 1430745 - IPC: Fix unaligned accesses in DirReaderLinuxJiaxun Yang2020-05-14
| | | | Tag: %1542
* Make the reference to Handle unambiguous in ↵Matt A. Tobin2020-03-31
| | | | | | ipc/testshell/XPCShellEnvironment.cpp .. correctly
* Revert "Make the reference to Handle unambiguous in ↵Matt A. Tobin2020-03-31
| | | | | | ipc/testshell/XPCShellEnvironment.cpp" This reverts commit d4afddfadab3108c26c8cab274d2cb32847c4d95.
* Make the reference to Handle unambiguous in ↵Matt A. Tobin2020-03-31
| | | | ipc/testshell/XPCShellEnvironment.cpp
* Issue mcp-graveyard/UXP%1471 - Fix building on sparc64 LinuxJMadgwick2020-03-09
| | | | | Correct various pre-processor defines for sparc64 and in mozjemalloc use the JS arm64 allocator on Linux/sparc64. This corrects build problems opn Linux sparc64 and is in line with bugzilla bug %1275204.
* Revert "Issue mcp-graveyard/UXP%190 - Part 1: Remove XP_IOS conditional code"Matt A. Tobin2020-02-28
| | | | This reverts commit 6a3d5769d01ec1a8dd56ea79aec2df91b801ce02.
* Issue mcp-graveyard/UXP%190 - Part 1: Remove XP_IOS conditional codeMatt A. Tobin2020-02-28
|
* Issue mcp-graveyard/UXP%1053 - Remove android support from ipc except for ↵Matt A. Tobin2020-02-22
| | | | | | ipc/chromium This does not include android in the imported chromium code as specific research needs done on defines and logic.
* Issue mcp-graveyard/UXP%1441 - Guard appomni/greomni with UXP_CUSTOM_OMNI ↵wolfbeast2020-02-14
| | | | | | | | env var. This adds an addition to the environment set up for child processes (plugin container) so that it may still be able to pass the omni parameters there as-needed.
* Issue mcp-graveyard/UXP%1342 - Remove support for system libeventwolfbeast2020-01-23
|
* No Issue - Fix indentation and account for system libevent in ↵Matt A. Tobin2019-12-17
| | | | ipc/chromium/moz.build
* Issue mcp-graveyard/UXP%457 - Fix typo in ↵athenian2002019-11-18
| | | | | | ipc/chromium/src/base/sys_info_posix.cc I made a typo in commit 687a789 when updating the ifdef style I used to comply with UXP standards. The typo I made resulted in a compiler warning I failed to notice, so I was asked to tag issue %457 when submitting the PR. I also fixed some trailing whitespace I apparently left behind in the file.
* Fix nits.athenian2002019-10-31
| | | | I hope this addresses everything.
* MoonchildProductions%1251 - Part 27: Fix ifdef style.athenian2002019-10-21
| | | | This should do it for all the commits to files I changed, but while I'm in here I could probably go ahead and turn ALL the singular if defined statements into ifdef statements by using grep/find on the tree. On the other hand, perhaps we should do that as a separate issue so that this doesn't become a case of scope creep.
* MoonchildProductions%1251 - Part 23: Allow AMD64 build to work.athenian2002019-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS Setting this up turned out to be easier than I thought it would be. All I had to do was apply these instructions in reverse and add the following to my .mozconfig file: CC="gcc -m64" CXX="g++ -m64" AS="gas --64" ac_add_options --target=x86_64-pc-solaris2.11 export PKG_CONFIG_PATH=/usr/lib/amd64/pkgconfig ac_add_options --libdir=/usr/lib/amd64 ac_add_options --x-libraries=/usr/lib/amd64 Most of these changes were fairly trivial, just requiring me to make a few of the changes I made earlier conditional on a 32-bit build. The biggest challenge was figuring out why the JavaScript engine triggered a segfault everytime it tried to allocate memory. But this patch fixes it: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/web/firefox/patches/patch-js_src_gc_Memory.cpp.patch Turns out that Solaris on AMD64 handles memory management in a fairly unusual way with a segmented memory model, but it's not that different from what we see on other 64-bit processors. In fact, I saw a SPARC crash for a similar reason, and noticed that it looked just like mine except the numbers in the first segment were reversed. Having played around with hex editors before, I had a feeling I might be dealing with a little-endian version of a big-endian problem, but I didn't expect that knowledge to actually yield an easy solution. https://bugzilla.mozilla.org/show_bug.cgi?id=577056 https://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html As far as I can tell, this was the last barrier to an AMD64 Solaris build of Pale Moon.
* MoonchildProductions%1251 - Part 22: Remove some unused type declarations ↵athenian2002019-10-21
| | | | | | | | | | from IPC process_util. https://bugzilla.mozilla.org/show_bug.cgi?id=1397928 Was looking into that _POSIX_PATH_MAX/NAME_MAX issue earlier because it didn't make a lot of sense and I was thinking of other approaches besides char arrays, and I wanted to make sure it didn't cause problems after they did it. Turns out that one commit after this was added, Mozilla determined the code I was working on fixing to be dead code as of Firefox 58. I don't know if it's dead code in Pale Moon as well, but given that it compiles fine without it and I can't find any other references to szExeFile in the IPC code, that seems like a safe bet. Besides, I determined config/pathsub.c already seems to do what this code looks like it's trying to do, and implements the solution of just defining NAME_MAX to 256 and having done with it that I nearly adopted after realizing that even OS/2 and BeOS, let alone Unix/Linux systems, all basically use that value and there's just disagreement on which system header to check for it.
* Fix a bunch of dumb typos and omissions.athenian2002019-10-21
|
* MoonchildProductions%1251 - Part 10: ipc_channel_posix.cc should use IOV_MAX.athenian2002019-10-21
| | | | | | | | | | | | https://bugzilla.mozilla.org/show_bug.cgi?id=1345102 I assess this change to be low-risk for the following reasons: 1. It has been in Firefox since version 55 without issues. 2. The current behavior is not POSIX compliant, and is retained in the one instance where the new functionality causes issues. 3. It makes safer assumptions about implementation details than what we have now.
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-10 04:54:20 +0000