This is being used in match_identifier_name(), for example when parsing
property keys - the list was incomplete, likely as some token types were
added later, leading to some unexpected syntax errors:
> var e = {};
undefined
> e.extends = "a";
e.extends = "a";
^
Uncaught exception: [SyntaxError]: Unexpected token Extends. Expected IdentifierName (line: 1, column: 3)
Fixes#3128.
This was using window()->position(), which is unset for windows with
WindowType::MenuApplet. Now it checks the window type and then uses
rect_in_menubar() for MenuApplet windows and rect() for everything else.
This makes tooltips show up for MenuApplet windows, previously they were
positioned off-screen :^)
If the space cannot be allocated, the original memory block shall remain
unchanged and the function should return nullptr.
Also add a function attribute and some null checks.
Previously the ColorPicker would get the custom color directly from the
window, this was changed in d7d5788469 to
get the color from the underlying bitmap instead - without taking the
bitmap's scaling into effect though, so resulting colors were off by
quite a bit.
Fixes#3113.
Subtracting 128 from the desktop rect's height was far to much and
and leading to weird rendering issues - now it's calculated exactly from
taskbar and menubar heights as well as a little additional offset to
make it fit perfectly.
Fixes#3115.
This fixes an issue where transparent pixels in GIF animation frames
have their alpha values incorrectly set to zero, allowing the
background behind the GIF to show through, instead of the previous
animation frame.
Additionally, transparent pixels are now correctly identified based on
their index matching the image transparency index, instead of their
color values.
This adds a new header <sys/internals.h>, which provides access to LibC internals.
This is in the interest of type-checking LibC itself, as well as enabling less-hacky
access for uses like LinkDemo.
And, of course, this progresses LibC towards building cleanly with -Wmissing-declarations.
I'm not sure how else to handle this. Curiously, I can't find the string '_start'
anywhere else in the project. Could it be that we haven't NIH'd this yet?
And that we actually rely on magic from the compiler to call _start for us?
This enables a nice warning in case a function becomes dead code.
For example with the unused function malloc_good_size() :^)
I found these places by using -Wmissing-declarations.
The Kernel still shows these issues, which I think are false-positives,
but don't want to touch:
- Libraries/LibC/crt0.cpp:41:5: int _start(int, char**, char**)
Not sure how to handle this.
- Libraries/LibC/cxxabi.cpp:48:5: int __cxa_atexit(AtExitFunction, void*, void*)
- Libraries/LibC/cxxabi.cpp:58:6: void __cxa_finalize(void*)
Not sure how to tell the compiler that the compiler is already using them.
- Libraries/LibC/libcinit.cpp:36:6: void __libc_init()
- Libraries/LibC/libcinit.cpp:55:19: void __stack_chk_fail()
- Libraries/LibC/malloc.cpp:430:6: void __malloc_init()
- Libraries/LibC/stdio.cpp:562:6: void __stdio_init()
These are ninja-imported by other LibC functions.
Maybe we should have some kind of "internals.h" header.
This enables a nice warning in case a function becomes dead code. Also, in the
case of {Event,Node}WrapperFactory.cpp, the corresponding header was forgotten.
This would cause an issue later when we enable -Wmissing-declarations.
Is my clang-format misconfigured? Why is the diff for NodeWrapperFactory.cpp
so large?
Code is pretty trivial. If someone needs "float" support, a copy-paste
will be in place.
Build system was confused between math.h from rootfs, and toolchain. I
fixed the problem caused by `math.h` by locally using the builtin
`isnan()` from the compiler. It's ugly - but works. I am looking for
other alternatives.
This patch makes images have an implicit zero intrinsic size before
they have either loaded or failed to load. This is tracked by the
ImageLoader object.
This fixes a long-standing issue with images occupying empty 150x150
rectangles of space.
This is to prevent bugs like #3091 (fixed in
9810f8872c21eaf2aefff25347d957cd26f34c2d) in the future; we generally
don't want Interpreter::run() to be called if the interpreter still has
an exception stored. Sure, it could clear those itself but letting users
of the interpreter do it explicitly seems sensible.
We don't want to carry over exceptions across multiple
Document::run_javascript() calls as Interpreter::run() and every of its
exception checks will get confused - in this case there would be an
exception, but not because a certain action failed.
Real-life example:
<script>var a = {}; a.test()</script>
<script>alert("It worked!")</script>
The above HTML will invoke Document::run_javascript() twice, the first
call will result in a TypeError, which is still stored during the second
call. The interpreter will eventually call the following functions (in
order) for the alert() invocation:
- Identifier::execute()
- Interpreter::get_variable()
- Object::get() (on the global object)
That last Object::get() call has an exception check which is triggered
as we still carry around the exception from earlier - and eventually
returns an empty value.
Long story short, the second script will wrongly fail with
"ReferenceError, 'alert' is not defined".
Fixes#3091.
