This is essentially a follow up to Issue #1286. We already have
UCHAR_EXTENDED_PICTOGRAPHIC in our in-tree ICU, so there's no reason to comment
this case out.
Windows commonly fails to work because of --compressed, and its string
escaping needed improvement because of the complexities of argument
parsing in command windows.
In CanvasRenderingContext2D::SetFontInternal, we should not throw if
there is no PresShell due to (sandboxed/hidden) iframe use that has not
initialized its presentation yet at the time of property manipulation.
This removes the throwing of the error and just silently fails.
Resolves#2087
Don't mark the .kPStaticModules section as relro for bfd, as the linkers on
Windows and Mac don't do this anyway.
Add a section insert of .kPStaticModules to config/expandlibs_exec.py, which
seems to be the primary cause of linking bustage on gold, lld, and mold.
The first part also means that Compact no longer needs the SurfaceCache lock (used to be via CreateChunk->CanHold),
which avoids potential deadlocks during shutdown that m-c 523950 would otherwise cause
Controlled by image.animated.decode-on-demand.threshold-kb, default 256MB
Includes squashed bugfixes/regressions:
- m-c 1444537: Shutting down the decode pool should make animated decoders bail early
- m-c 1628606: Make sure to mark the surface cache entry available before sending the frame complete notification
- m-c 1502275: Skip recreating the decoder after redecode errors if an animated image is reset
- m-c 1443232: Don't insert frames into our AnimationFrameBuffer that we consider in error and unusable
Includes squashed changes of:
- m-c 1317907: Refactor FrameAnimator::GetCompositedFrame to be a bit simpler
- m-c 1351434: bugfix
- m-c 686905: Enable the pref image.mem.animated.discardable to allow discarding of animated images
Regression seems to have been introduced by PR #2060? This tree didn't fail
building before we've reinstated unified building for js/src.
Found while building js/src de-unified.
We may eventually want to make this permanent in the front-end of
Pale Moon for privacy reasons.
Disabling this to avoid usage expecting changed spec results.
This implements a plain interpretations of RFC 6797, which says to only consider
the first HSTS header.
This slightly conflicts with RFC 7230, which says that sending multiple headers
which can't be merged is illegal (except for a specific whitelist which HSTS isn't in),
so this situation should never occur in the first place (and would therefore not need
the explicit entry in RFC 6797).
It improves HSTS robustness dealing with non-compliant servers.
Resolves#2070
Remove stuff from /extra/ and the JPEG transcoding file from compilation, as
we don't need them.
A disable define for box decoding is also added, but currently commented out as
there's no need to disable the function right now.
Co-authored-by: Moonchild <moonchild@palemoon.org>
I'm not sure about what they had in mind when they first wrote this, but this is completely unnecessary. The base name is the file name. This part will break building with `mach faster` once partial filenames with wildcards are included in the package manifest, which became the case when we began supporting the newer MSVC runtime.
This also aligns FasterMake with how RecursiveMake treats wildcard copy directives.
They fixed this in bug 1416465, but it included a conditional that will almost always be true and kept this incorrect joining of the path and base name in the destination path. Since the value for the base name is either empty or contains a partial file name, that conditional effectively does nothing.
I use this for quickly rebuilding and preprocessing the JS/XUL/CSS assets them without the need to recompile the IDL interfaces and other unnecessary items.
Fixes building on Windows.
I also decided to move the preprocessed jxl/version.h to our include/jxl
instead of relying on moz.build in preprocessing the file. Future me
should note to not forget to update the version number at that new file
- RegExpParser collects seen groups in named_captures_.
- After irregexp::ParsePattern has finished, RegExpParser::StoreNamedCaptureMap translates
the parser data to RegExpCompileData.capture_name/index
- RegExpShared::initializeNamedCaptures takes these and builds a PlainObject map which
is kept with the compiled expression
This is done because irregexp doesn't have access to the JS context and so can't allocate
any JSValues itself.
- for each match result, this map is used to build PlainObjects of name->match/undefined
(extremely simplified from upstream at the expense of some perf)
IonMonkey switches to non-masm code path for expressions with named groups.
- Port unification of CheckNotBackReference*
- Port LoadCurrentCharacter
- Make RegExpMacroAssembler::CheckAtStart understand cp_offset
- Replace magic numbers in ChoiceNode::Emit, Trace::PerformDeferredActions
- CheckBacktrackStackLimit
- Allow backrefs to resist recursion
Per Issue #2033 we don't support expanding RGB to RGBA yet, so this opacity
check will always return RGBX, which makes images with transparent backgrounds
show up with a black background instead. Feel free to readd once we backport
Mozilla bug 1551088.
Based on Mozilla phab D122159, intended for bug 1709815.
Also moved the temporary RGBA and premultiplication fixes to a macro, since
progressive decoding also needs these fixes.
Based on selected bits of M-C 1461708:
- EventStateManager::CheckForAndDispatchClick() to early-return style
- split EventStateManager::CheckForAndDispatchClick() into:
EventCausesClickEvents, PostHandleMouseUp, DispatchClickEvents
- Move implementation of UIEvent::GetRangeParent() and UIEvent::RangeOffset() to nsLayoutUtils
nsPluginInstanceOwner only listens to keypress events in the default event group.
However, in our changed operating mode, keypress events are not fired in the
default event group if the key does not result in something printable.
This means that nsPluginInstanceOwner should also listen to keypress events
in the system event group and should handle each keypress that way, but
only once. I.e., if a printable keypress event is received in the system event
group, it should be ignored, since it would've already been handled in the
default event group in that case.
We have a BGR/RGB channel ordering mismatch here. to at least
provide proper display, a quick&dirty byte swap on the output
buffer will fix this for now, but we should look into seeing where
the surface mismatch is caused.
std::swap() should optimize pretty well in any of the used
compilers, but if necessary, a full buffer ASM routine can be
slotted in (although on current hardware I doubt this will be
even noticeable as it is)
nsPluginInstanceOwner only listens to keypress events in the default event group.
However, in our changed operating mode, keypress events are not fired in the
default event group if the key does not result in something printable.
This means that nsPluginInstanceOwner should also listen to keypress events
in the system event group and should handle each keypress that way, but
only once. I.e., if a printable keypress event is received in the system event
group, it should be ignored, since it would've already been handled in the
default event group in that case.
We have a BGR/RGB channel ordering mismatch here. to at least
provide proper display, a quick&dirty byte swap on the output
buffer will fix this for now, but we should look into seeing where
the surface mismatch is caused.
std::swap() should optimize pretty well in any of the used
compilers, but if necessary, a full buffer ASM routine can be
slotted in (although on current hardware I doubt this will be
even noticeable as it is)
Following the behavior of the download dialog, the content handling dialog should be `dependent` as well. This means that this dialog should close when the parent window is closed, is not visible on the taskbar, and stays in front of the parent window.
Sets the pref default to true and also add conneg entry for images
if jxl support is built.
Additionally, ifdefs the GfxPref to only observe when jxl is built.
Based on FranklinDM's follow-up for the issue.
This would require browser FE changes, particularly removing the associated
code in `tabbrowser.xml`, however, that was already done in Pale Moon previously.
Other front-end applications may need to take note, though.
Based on changes from the following bugs:
* Bug 696398 - Need an api to analyze panning performance
* Bug 800031 - Include paint time in tab switch telemetry
* Bug 820167 - Enable performance measurement of tab animation
* Bug 826383 - Improve Start/Stop FrameTimeRecording for telemetry usage
This change modifies the mozdebug module to include a special case for Visual Studio when looking for its path.
This also removes the workaround implemented in dcb027a718 which can break debugging in certain installations of Visual Studio 2015.
The autocomplete module listens to keypress events for both printable keys
and non-printable keys a lot. However, we're stopping dispatching keypress
events for non-printable keys in the default event group of web content.
This means that autocomplete should listen to keypress events in the
system event group.
Note that it's difficult to globally change keypress event listeners to
keydown event listeners because if we stop keypress events at preceding
keydown event in autocomplete or satchel modules, some other modules
fail to handle keydown or keypress events before autocomplete, and it's
not easy to investigate which keypress event listener in which modules
should be changed to a keydown event listener.
Therefore, this patch doesn't do that, and uses the event group approach.
Since keypress is no longer triggered on all keypresses in content,
the spellchecker would potentially not be triggered when it should be.
This changes the trigger to keydown, instead.
No behavioral changes otherwise.
This will prevent the keypress DOM event from firing on keypresses
that do not produce printable keys (e.g. editing nav keys) in content.
This should not affect any chrome events that are in use.
Event dispatch can be re-enabled if necessary with the added pref.
I didn't catch this because I am used to the .jsm files being imported near the
top of the file, not later on. This is the case in the other two files I
worked on. Only AddonUpdateChecker.jsm seems to have this problem.
I also use the pref as a constant rather than calling the pref service
repeatedly to make code look much neater. APPCOMPATID matches
APPCOMPATVERSION, and doesn't give the vibe of a sneaky young lad trying to
enter into a tavern whilst underage.
This does 2 things.
First, it adds parsing of the 's' parameter parsing to DOM object construction of regexes
Second, it corrects the DOM property to be `dotAll` instead of `dotall`
For consistency's sake, all function names and calls were renamed with the finalized casing.
This resolves#2008
This has been long deprecated in favor of std::unsorted_map. Since all platforms
are using modern compilers now it should not be a problem to switch over to
std::unsorted_map in the single place hash_map is used. This allows us to build
on platforms which have removed hash_map such as FreeBSD.
The python binary copied reports a valid signature on Big Sur and thus codesign fails.
Add the -f option so it overwrites the supposedly valid signature. Other versions are
either already unsigned or the install_name_tool invalidates the signature.
The current spec makes "implicit" parentheses a thing for feeding
css strings to CSS.supports()
The current spec also implies CSS is a namespace, not an interface
1334081 - prevent null pointer dereference in StreamReaderFunc.
1330631 - Convert the EventSourceImpl::Message to be UniquePtr.
1337619 - Reset mGoingToDispatchAllMessages flag before early return.
Almost forgot to do this. This is in case we need to revisit this for
regressions in the future and the tests are not available online. Never know
when they might come in handy again.
Configure was defining HAVE_ARC4RANDOM_BUF on systems that have it this whole
time, so the OS specific ifdefs weren't necessary. Maybe the flag that was in
the original patch was an obsolete name for that flag...
It turns out part 10 was actually needed, but Bug 1449838 had a significantly
better version of what that code does that was easy enough to backport to what
we have. As far as I can tell, this passes the relevant reftests now.
My previous fix apparently only worked with GCC 7. Having that return at the
end doesn't seem to hurt anything on Windows, so I see no reason to ifdef it.
I don't remember where I heard this, but I vaguely remember hearing that
ending a function without a return statement may be undefined behavior that
differs between compilers and operating systems. If so, that would explain why
this has behaved so differently across platforms and compilers.
This was a control issue way back when. Since this only really relates to
deviating build configs anymore and no longer to critical system libs of note,
there's no point in retaining this overbearing control through build errors.
People have clear instructions how to build - it is their responsibility to
stick to those.
Turns out we have a duplicate VoidFunction callback in the WebIDLs. Per
Mozilla bug 1324169, we should remove this callback from
RTCPeerConnection.webidl and let Function.webidl handle it instead.
The AttributeError faced by the new Basilisk dev wasn't helpful at all;
and turns out Mozilla had this exact same issue on bug 1505504. We're
also backporting that just in case we encounter another case of
callback duplication.
Also doing a minor fix in the MicroTaskRunnable class which Moonchild
forgot to do while working on Issue #1895.
Based on Mozilla bugs 1270140, 1504656, 1483545, and 1504334.
Took note of Mozilla bug 1379222 which changed GetPrototypeFromCallableConstructor
to GetPrototypeFromBuiltinConstructor.
There are many other changes I did myself since the initial implementation by
Mozilla wouldn't work with this codebase.
The issue is that select elements may contain some non-Latin characters that
need extra block-size to display than the one line-height calculated by using a
Latin font spec in the style.
Before this patch, when a control has an unconstrained block-size, we set
the element's block-size to one line-height in Reflow(), which is intended to
properly initialize `BlockReflowInput::mMinLineHeight` since it uses
`line-height:-moz-block-height`.
However, this simply prevents the display from choosing a larger block-size
after the reflow occurs. Previously, this discrepancy was absorbed by the extra
padding present to make select elements the same intrinsic size as buttons, but
since we did away with that, we're losing the extra space and the font glyphs
get clipped.
This patch fixes the issue by carrying the computed line height over to the
element's display so that its computed block-size is still unconstrained.
This way it can accommodate taller characters in the display text.
After this patch, a <select><option> containing non-Latin characters should have
the same block-size as <button>, and no characters should be clipped.
To better distinguish the calculation of line height (still present with args)
and simply getting the line height without args, it's now called GetLineHeight()
This also introduces `mLineHeight` to cache specifically calculated line heights
that aren't "auto" (which is a magic value), and it opens up the possibility to
override it in Part 7.
This doesn't change behavior by default but allows authors to remove the padding
previously enforced to align with focus ring padding, if they wish to.
Removed some obsolete patches that were either backports from newer
svn revisions, or a fix for older, non-applicable assemblers.
Update our own README to account for upstream's migration to git.
I didn't remove the bug 703135 patch as it's for MSVC it seems, and
we still use MSVC for Windows.
Also deleted some unneeded upstream code deleted by Mozilla as well.
Extra padding was created for a prospective -moz-focus-inner ring.
We now just size that ring the same as the content frame, inflated by its CSS
padding.
Removed some obsolete patches that were either backports from newer
svn revisions, or a fix for older, non-applicable assemblers.
Update our own README to account for upstream's migration to git.
I didn't remove the bug 703135 patch as it's for MSVC it seems, and
we still use MSVC for Windows.
Also deleted some unneeded upstream code deleted by Mozilla as well.
This allows us to use a greater rendering depth for exceedingly-deep DOM trees
in layout, better matching what mainstream browsers are capable of. Note that
for 32-bit Windows the stack size MUST be set to larger than the default or Bad
Things Will Happen™ - we use 1.5 MB for this as a carefully-tuned value.
This needs to be capped specifically for JS use because some JavaScript
obfuscators deliberately trigger stack overflows and would lock up the browser
otherwise as long as there's still stack space to abuse. For web compatibility
we therefore limit this to 2MB in JS only (3x for ASAN) while still allowing
a greater depth for the layout engine.
Newer MSVC was failing to find the devenv executable for ./mach run --debug
This isn't the prettiest solution, but at least it's better than just relying
on a hardcoded path.
I moved Range<bool>::Merge and Range<bool>::FinalizeMerge from MediaTrackConstraints.cpp, into MediaTrackConstraints.h. The header file previously contained only a forward declaration of functions implemented in the .cpp, which can be a problem if other parts of the program are including this header expecting to find the function.
I don't know how Mozilla was able to build this without defining
ST_NO_EXCEPTION_HANDLING, but looks like we have to do it so that
the compiler doesn't complain about -fno-exceptions
I separated out the AVC and AAC support code into a patch file so that
the upstream code can be updated freely without having to re-add AVC
and AAC support again. At least if the upstream changes are not too
extensive...
This should effectively backport Mozilla bug 1539686, which allows the
browser to parse the color information from WebM videos that uses HDR.
highway upstream added a new header file to be included in highway.h after
0.15.0 it seems, so we have to account for that in moz.build.
Also brought back allowing compiler warnings for libjxl and highway.
Apparently the equivalent of AllowCompilerWarnings() is a bool whose name
is UPPERCASE and uses under_scores instead of CamelCase.
The mp4parse Rust component has been removed in Issue #58. It doesn't seem
like the decoder uses any mp4parse function, so seems like it's safe to
remove it.
Removed const DecoderType named GetType() because we don't have it in our
Decoder.h.
I've decided to abandon the OS_RGBA backporting effort and instead went for
using OS_RGBA's value which is R8G8B8A8. Turns out that there is much more
going on in Mozilla's version of CreateSurfacePipe than I've expected, like
the aInFormat and aOutFormat thing which I really don't want to delve into
right now. Looking at the code it looks like all JPEG-XL images are expected
to have an alpha channel anyway, so I think my workaround should be safe.
I also removed the dependency in OrientedIntSize and used Size() from gfx/2d/
Point.h like our PNG and GIF decoders currently do. Migrating our decoders
to OrientedInt types should be done in another PR instead.
Also also changed the coding style to be closer to UXP's.
Also also also, I made a mistake in Part 1's commit message; the commit used
for libjxl is 192ddd90fdf0c69cd1db1c8d7850db036dd87f4b.
Used old-configure to add the build option for enabling JPEG-XL support.
Highway version: 0.17.0
libjxl version: tree of commit 318c592d98b97d103941b90d47107f06a10c71da
This conditional was incorrectly changed when removing Android support.
This potentially causes issues on Linux systems by not using pthreads correctly,
which may lead to high idle CPU usage.
This conditional was incorrectly changed when removing Android support.
This potentially causes issues on Linux systems by not using pthreads correctly,
which may lead to high idle CPU usage.
Thankfully I already redundantly edited this file myself before to
account for updates in the source, and backed this up to another
location just in case the shell script breaks my build files,
which it did!
I've also added some notes in the update.sh script that should've been
documented, as well as changed README to README.md which Mozilla
somehow forgot to do when they updated to 1.3.3...
genUnicodePropertyData.pl's output:
unknown ICU script MASARAM_GONDI at ../tools/genUnicodePropertyData.pl line 442, <FH> line 2641.
unknown ICU script SOYOMBO at ../tools/genUnicodePropertyData.pl line 442, <FH> line 2663.
unknown ICU script ZANABAZAR_SQUARE at ../tools/genUnicodePropertyData.pl line 442, <FH> line 2679.
Data for CharProp2 = 14864
Data for FullWidth = 2176
Data for FullWidthInverse = 2688
Total data = 19728
In order to generate these files, refer to
https://wiki.mozilla.org/I18n:Updating_Unicode_version
For those too lazy to go to the link (or if the link no longer works), we need the
following files from http://www.unicode.org/Public/9.0.0/ucd/:
- UnicodeData.txt
- Scripts.txt
- EastAsianWidth.txt
- BidiMirroring.txt
- HangulSyllableType.txt
- SpecialCasing.txt
- ReadMe.txt (to record version/date of the UCD)
- Unihan_Variants.txt (from Unihan.zip)
As well as Identifier*.txt from http://www.unicode.org/Public/security/9.0.0/,
which should be put in a "security" subdirectory under the UCD folder, and
http://www.unicode.org/Public/vertical/revision-15/VerticalOrientation-15.txt put
in a "vertical" subdirectory.
I suggest downloading all files with GetEmAll, just in case.
Change the perl command a bit, as the guide seems to be outdated:
perl ../tools/genUnicodePropertyData.pl /path/to/platform/gfx/harfbuzz/src/ /path/to/platform/intl/icu/source/common/unicode/ /path/to/UCD-directory/
Backported from Mozilla bug 1472602.
Didn't include the change in StickyScrollContainer.cpp because it breaks
linking to libxul.so in the end. It's not important anyway.
Starting with SDK 10.14 I believe, many functions have main thread checks, including setView: and update.
So we now move the code in the updateGLContext method into doDrawRect which runs on the main thread.
When installing an incompatible add-on, the add-ons manager checks first if a newer and compatible version of that add-on is available by sending a request either to the AUS or the provided update URL in the manifest.
If there's no update URL in the manifest and if the application does not provide an add-on update URL via preferences, the add-ons manager will error out and fail to notify that the said add-on is incompatible.
This commit addresses that by:
(a) preventing substitutions on the update manifest URL - this throws an error if it's empty; and
(b) failing early in the add-on update checker if the update manifest URL is empty and sends out an error notification
We already blocked x-moz-file(-promise) and x-moz-place* but of course people
would find ways to abuse other internal types. This change now blocks everything
except x-moz-url types which are harmless. (i.e. whitelist instead of blacklist)
This commit adds a Content-Security-Policy to HTML documents for exported
bookmarks. The change will stop active content (like bookmarklets) from being
directly runnable in the exported local file, which is *not* breaking the
normal use case in which a bookmarklet is intended to modify an existing page.
It *will* affect the use case where you have a full website/application stored
in a bookmarklet that was supposed to replace the current web page. In this
case, users can right-click copy the link and drop it in the address bar.
Note: The CSP does not mean that this is a severe attack vector. It merely
provides a basic protection measure for users who use the exported bookmarks in
a non-standard way as a local file.
Some encoders will set ctts flags incorrectly (similar to version) resulting in
libstagefright aborting playback of media based on the media header.
(Looking at you, Twitter)
This change relaxes libstagefright's checking to pass ctts flags 0 or 1 and
falls through to actually trying to decoding the file.
pointers for shapes.
Nobody likes "isNullLike(obj)" when trying to garbage collect. It either is or
is not. Master Yoda would be pleased with this change.
I'm very confident these changes will not impact IceDove-UXP or Pale Moon. What they do is conditionally disable a button that allows people to get a new account from a Mozilla-advertised e-mail provider, and remove the hard-coded OAuth2 keys in favor of a user-controlled preference.
This uses a different approach by modifying the `Boolish` function directly to act differently if we're checking for nullish values.
Partially based on:
Bug 1566141 - Implement the Nullish Coalescing operator (??) proposal
Bug 1599163 - Nullish coalescing operator returns undefined for void expressions
Partially based on:
Bug 1566141 - Implement the Nullish Coalescing operator (??) proposal
Bug 1593415 - Assertion failure: false, at js/src/builtin/ReflectParse.cpp:3092 with nullish coalescing
As part of telemetry removal, d60103257e removed the `reportResult` function which also handles the stopping of the sanity test. This also removes unused histogram enumeration values and revises/adds some comments.
Some hoops to make sure the test still works if the default value for the pref
is false, requiring setting and resetting it and making sure the observers have
time to react to these changes before testing.
Even if `<datalist>` is dynamically changed, the autocomplete controller still
uses the previous search result. If changed, we have to ignore the previous
result that may now be invalid.
Also, even if `<datalist>` is changed, we have to keep the selected index
(See Mozilla Bug 595069), so we cannot use `ResetInternalState` in this
situation because it resets the selected index.
This resolves#1509.
@# If we're using the hybrid FasterMake/RecursiveMake backend, we want
@# to ensure the FasterMake end doesn't have install manifests for the
@# same directory, because that would blow up
$(if$(wildcard _build_manifests/install/$(subst /,_,$*)),$(if$(wildcard faster/install_$(subst /,_,$*)*),$(error FasterMake and RecursiveMake ends of the hybrid build system want to handle $*)))
@@ -33,5 +33,7 @@ If you fork this repository to perform your own work on it, please consider offe
improvement patches upstream to its origin to mutually improve the platform and build
a future for XUL.
## Looking for Pale Moon and Basilisk?
As of [`Issue #969`](https://repo.palemoon.org/MoonchildProductions/UXP/issues/969), release versions`28.9.0` and `2020.03.04` respectively, they have been split off into their own dedicated repositories located at [`MoonchildProductions/Pale-Moon`](https://repo.palemoon.org/MoonchildProductions/Pale-Moon) and [`MoonchildProductions/Basilisk`](https://repo.palemoon.org/MoonchildProductions/Basilisk).
## Looking for Pale Moon?
As of [`Issue #969`](https://repo.palemoon.org/MoonchildProductions/UXP/issues/969), release version `28.9.0`,
applications have been split off into their own dedicated (front-end) repositories, with Pale Moon located at
Loaded 100 of 7125 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.