WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
173757
[WPE] Use JSC API to send script messages from web extension in tests
https://bugs.webkit.org/show_bug.cgi?id=173757
Summary
[WPE] Use JSC API to send script messages from web extension in tests
Carlos Garcia Campos
Reported
2017-06-22 23:47:45 PDT
The GTK+ port uses DOM bindings for that. This will fix /wpe/WebKitSecurityManager/file-xhr and all TestConsoleMessage
Attachments
Patch
(7.21 KB, patch)
2017-06-22 23:52 PDT
,
Carlos Garcia Campos
zan
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Carlos Garcia Campos
Comment 1
2017-06-22 23:52:00 PDT
Created
attachment 313694
[details]
Patch
Zan Dobersek
Comment 2
2017-06-23 03:10:01 PDT
Comment on
attachment 313694
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=313694&action=review
> Tools/TestWebKitAPI/Tests/WebKitGLib/WebExtensionTest.cpp:266 > + GUniquePtr<char> escapedMessageString(static_cast<char*>(g_malloc(strlen(messageString.get()) * 2 + 1))); > + char* src = messageString.get(); > + char* dest = escapedMessageString.get(); > + while (*src) { > + if (*src == '"') { > + *dest++ = '\\'; > + *dest++ = '"'; > + } else > + *dest++ = *src; > + src++; > + } > + *dest = '\0';
Would it be possible to use something like g_strescape() here? And use g_strcompress() on the receiving end, if necessary or possible? Apart from that, src++ should be ++src.
Carlos Garcia Campos
Comment 3
2017-06-23 04:06:45 PDT
(In reply to Zan Dobersek from
comment #2
)
> Comment on
attachment 313694
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=313694&action=review
> > > Tools/TestWebKitAPI/Tests/WebKitGLib/WebExtensionTest.cpp:266 > > + GUniquePtr<char> escapedMessageString(static_cast<char*>(g_malloc(strlen(messageString.get()) * 2 + 1))); > > + char* src = messageString.get(); > > + char* dest = escapedMessageString.get(); > > + while (*src) { > > + if (*src == '"') { > > + *dest++ = '\\'; > > + *dest++ = '"'; > > + } else > > + *dest++ = *src; > > + src++; > > + } > > + *dest = '\0'; > > Would it be possible to use something like g_strescape() here? And use > g_strcompress() on the receiving end, if necessary or possible?
The problem is not the receiving end, but JSC. If we pass something like "Foo"bar"Baz" the script fails to run, so it never gets to the other end. We don't receive anything escaped in the other end. Also we would need to add ifdefs in the UI process side too. I started using g_strescape(), but the problem is that it escapes all non ascii characters, making the test fail, because one of the error messages uses utf8. So, since what we only need is escaping " because we are passing "%s" to JSC, I thought it was simple enough to do it here.
> Apart from that, src++ should be ++src.
Ok, just curiosity, does it make any difference in this case?
Carlos Garcia Campos
Comment 4
2017-06-23 05:03:28 PDT
Committed
r218743
: <
http://trac.webkit.org/changeset/218743
>
Zan Dobersek
Comment 5
2017-06-23 05:05:32 PDT
(In reply to Carlos Garcia Campos from
comment #3
)
> > Apart from that, src++ should be ++src. > > Ok, just curiosity, does it make any difference in this case?
Not in terms of correctness, but it's good practice to always use the prefixed increment for this.
Zan Dobersek
Comment 6
2017-06-23 05:05:50 PDT
(In reply to Zan Dobersek from
comment #5
)
> (In reply to Carlos Garcia Campos from
comment #3
) > > > Apart from that, src++ should be ++src. > > > > Ok, just curiosity, does it make any difference in this case? > > Not in terms of correctness, but it's good practice to always use the > prefixed increment for this.
... where possible.
Michael Catanzaro
Comment 7
2017-06-23 15:34:33 PDT
Maybe for with user-defined increment operators, but for a primitive type like int, I don't think so... all compilers should know that they are the same if the value is not used as part of another expression, so I'd be surprised if the generated code was different, and the postincrement form is more natural and familiar. Doesn't matter, though.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug