Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of changes #11

Merged
merged 3 commits into from Jan 20, 2023
Merged

Rollup of changes #11

merged 3 commits into from Jan 20, 2023

Conversation

ghost
Copy link

@ghost ghost commented May 20, 2022

e18ef0fd85691b817158ba532ab5454e27b13fd1 requires https://review.haiku-os.org/c/haiku/+/4571 to be merged first

@ghost
Copy link
Author

ghost commented Jun 5, 2022

This should be good to go now.
One minor issue is that button border color is not exposed, even though we have this. Webkit seems to be missing a var here.

And for another thing the default canvas and default link color etc don't seem to be used in the default html document :D.
But that can be tackled later.

As an additional thing the Haiku: support rendering dark/light controls patch fixes a todo with clicking state and exposes the hovered state of webkit buttons to the controllook. Which means now buttons in native drawing respond to hovering, hooray.

@ghost
Copy link
Author

ghost commented Jul 23, 2022

-1
I want to rework this a bit, the colorForValue call should be shared instead.

The commit currently will also pick the wrong scrollbar thumb color.

@ghost
Copy link
Author

ghost commented Jul 25, 2022

Okay, the review is ready.
I need to test it once more with my haiku commit merged now, but it should be good to go!

@ghost
Copy link
Author

ghost commented Jul 25, 2022

I've talked to upstream, the change in Source/WebCore/html/ImageDocument.cpp I will submit to webkit directly (they also had a similar change for text documents recently, which is nice!)

The document color can be set in FrameView::setBaseBackgroundColor, I will investigate that tommorow, additionally upstream also has a pr to go from text->CanvasText, but it should likely be sufficient to add the css value for "text" to the system color thing (https://bugs.webkit.org/show_bug.cgi?id=232954)

Link color might be a bit more finicky, upstream also has issues with it
(https://bugs.webkit.org/show_bug.cgi?id=209851)

@ghost
Copy link
Author

ghost commented Jul 26, 2022

WebKit#2734

@ghost
Copy link
Author

ghost commented Jul 29, 2022

Another equivalent change for CanvasText instead of text was merged in webkit, I would redo this with the next versioing commit, or alternatively prepare a PR for the next versioing commit, and then rebase the LR on that.

(currently there is a bit of an issue to get the image one merged, seems I brole the webkit tool, but I'll resubmit it via their bugzilla next werk if the tool still fails then)

@pulkomandy
Copy link
Member

I can merge the WebKit upstream without waiting for an upstream "versioning" commit if that helps (and if the intermediate commit actually builds and runs, often they are broken if I just pick a random one).

@ghost
Copy link
Author

ghost commented Jul 31, 2022

Okay, that's good to know!
I think this WebKit#2706 still needs to be merged and my images commit, I'll let you know once that is done.

pulkomandy pushed a commit that referenced this pull request Nov 22, 2022
…a rejected promise

https://bugs.webkit.org/show_bug.cgi?id=247785
rdar://102325201

Reviewed by Yusuke Suzuki.

Rest parameter should be caught in async function. So, running this
JavaScript program should print "caught".
```
async function f(...[[]]) { }
f().catch(e => print("caught"));
```

V8 (used console.log)
```
$ node input.js
caught
```

GraalJS
```
$ js input.js
caught
```

https://tc39.es/ecma262/#sec-async-function-definitions
...
AsyncFunctionDeclaration[Yield, Await, Default] :
    async [no LineTerminator here] function BindingIdentifier[?Yield, ?Await] ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }
    [+Default] async [no LineTerminator here] function ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }

AsyncFunctionExpression :
    async [no LineTerminator here] function BindingIdentifier[~Yield, +Await]opt ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }
...

According to the spec, it indicates `FormalParameters` is used for Async
Function, where `FormalParameters` can be converted to `FunctionRestParameter`.

https://tc39.es/ecma262/#sec-parameter-lists
...
FormalParameters[Yield, Await] :
    [empty]
    FunctionRestParameter[?Yield, ?Await]
    FormalParameterList[?Yield, ?Await]
    FormalParameterList[?Yield, ?Await] ,
    FormalParameterList[?Yield, ?Await] , FunctionRestParameter[?Yield, ?Await]
...

And based on RS: EvaluateAsyncFunctionBody, it will invoke the promise.reject
callback function with abrupt value ([[value]] of non-normal completion record).

https://tc39.es/ecma262/#sec-runtime-semantics-evaluateasyncfunctionbody
...
2. Let declResult be Completion(FunctionDeclarationInstantiation(functionObject, argumentsList)).
3. If declResult is an abrupt completion, then
    a. Perform ! Call(promiseCapability.[[Reject]], undefined, « declResult.[[Value]] »).
...

In that case, any non-normal results of evaluating rest parameters should be
caught and passed to the reject callback function.

To resolve this problem, we should allow the emitted RestParameterNode be wrapped
by the catch handler for promise. However, we should remove `m_restParameter` and
emit rest parameter byte code in `initializeDefaultParameterValuesAndSetupFunctionScopeStack`
if we can prove that change has no side effect. In that case, we can only use one
exception handler.

Current fix is to add another exception handler. And move the handler byte codes to
the bottom of code block in order to make other byte codes as much compact as possible.

Input:
```
async function f(arg0, ...[[]]) { }
f();
```

Dumped Byte Codes:
```
...

bb#2
Predecessors: [ #1 ]
[  20] mov                dst:loc9, src:<JSValue()>(const0)
...

bb#3
Predecessors: [ #2 ]
[  29] get_rest_length    dst:loc11, numParametersToSkip:1
...

bb#12
Predecessors: [ #8 #9 #10 ]
[ 138] new_func_exp       dst:loc10, scope:loc4, functionDecl:0
...

bb#13
Predecessors: [ ]
[ 170] catch              exception:loc10, thrownValue:loc8
[ 174] jmp                targetLabel:8(->182)
Successors: [ #15 ]

bb#14
Predecessors: [ #7 #11 ]
[ 176] catch              exception:loc10, thrownValue:loc8
[ 180] jmp                targetLabel:2(->182)
Successors: [ #15 ]

bb#15
Predecessors: [ #13 #14 ]
[ 182] mov                dst:loc12, src:Undefined(const1)
...

Exception Handlers:
	 1: { start: [  20] end: [  29] target: [ 170] } synthesized catch
	 2: { start: [  29] end: [ 138] target: [ 176] } synthesized catch
```

* JSTests/stress/catch-rest-parameter.js: Added.
(throwError):
(shouldThrow):
(async f):
(throwError.async f):
(throwError.async let):
(async let):
(x.async f):
(x):
(async shouldThrow):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:

Canonical link: https://commits.webkit.org/256864@main
@ghost
Copy link
Author

ghost commented Jan 19, 2023

Should be good now. This commit doesn't fix the background color of the default html though. I will do that in a later commit if i can find a good way to do it.

This commit adds support to rendering light controls
in a light document even if the OS is in a dark mode
This is done by picking the default color from the OS
The same is done with dark controls
this is based on the color-scheme css property.

This commit makes controls use the configured OS colors.
Aswell as using the configured OS background color for the :root element

In addition this commit also provides default color values for css constants
based on the OS Settings
This makes light buttons get a dark text per default and dark buttons
get a light text by default.

This commit also enabled hover interactions for controls.

This commit fixes white screens between page loads.
@ghost
Copy link
Author

ghost commented Jan 20, 2023

This commit doesn't fix the background color of the default html though. I will do that in a later commit if i can find a good way to do it.

Fixed! It now does this aswell :)

@pulkomandy pulkomandy merged commit eb5d159 into haiku:haiku Jan 20, 2023
pulkomandy pushed a commit that referenced this pull request Mar 5, 2023
https://bugs.webkit.org/show_bug.cgi?id=251063
rdar://104585575

Reviewed by Mark Lam and Justin Michaud.

This patch enhances CallFrame::dump to support wasm frames in btjs stacktrace.
The example is as follows.

    frame #0: 0x00000001035fca78 JavaScriptCore`JSC::functionBreakpoint(globalObject=0x000000012f410068, callFrame=0x000000016fdfa9d0) at JSDollarVM.cpp:2273:9 [opt]
    frame #1: 0x000000010ec44204 0x10eccc5dc
    frame #2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined)
    frame #3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40)
    frame #4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40)
    frame #5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3)
    frame #6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0)
    frame #7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0)
    frame #8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame #9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame #10: 0x000000010ec3c728
    frame #11: 0x0000000103137560 JavaScriptCore`JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) [inlined] JSC::JITCode::execute(this=<unavailable>, vm=<unavailable>, protoCallFrame=<unavailable>) at JITCodeInlines.h:42:38 [opt]
    frame #12: 0x0000000103137524 JavaScriptCore`JSC::Interpreter::executeCall(this=<unavailable>, lexicalGlobalObject=<unavailable>, function=<unavailable>, callData=<unavailable>, thisValue=<unavailable>, args=<unavailable>) at Interpreter.cpp:1093:27 [opt]
    frame #13: 0x000000010349d6d0 JavaScriptCore`JSC::runJSMicrotask(globalObject=0x000000012f410068, identifier=(m_identifier = 81), job=JSValue @ x22, argument0=JSValue @ x26, argument1=JSValue @ x25, argument2=<unavailable>, argument3=<unavailable>) at JSMicrotask.cpp:98:9 [opt]
    frame #14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt]
    frame #15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt]
    frame #16: 0x00000001035e5894 JavaScriptCore`JSC::VM::drainMicrotasks(this=0x000000012f000000) at VM.cpp:1255:46 [opt]
    ...

* Source/JavaScriptCore/interpreter/CallFrame.cpp:
(JSC::CallFrame::dump const):

Canonical link: https://commits.webkit.org/259262@main
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants