Pass origin instead of host/port to Windows notification
Categories
(Toolkit :: Alerts Service, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox140 | --- | fixed |
People
(Reporter: saschanaz, Assigned: saschanaz)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Assignee | ||
Comment 1•22 days ago
|
||
This is to match NotificationDB that uses origin.
Updated•21 days ago
|
Updated•16 days ago
|
Backed out for causing xpc failures @test_backgroundtask_experiments.js.
Assignee | ||
Comment 5•3 days ago
•
|
||
Somehow the CI log doesn't have details, but local run shows it:
toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_experiments.js
FAIL toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_experiments.js - xpcshell return code: 0
ERROR Unexpected exception TypeError: can't access property "args", infoMap.showAlert is undefined at D:/gecko/obj-aarch64-pc-windows-msvc/_tests/xpcshell/toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_experiments.js:189
test_backgroundtask_caps@D:/gecko/obj-aarch64-pc-windows-msvc/_tests/xpcshell/toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_experiments.js:189:15
async*_run_next_test/<@d:\gecko\testing\xpcshell\head.js:1759:22
_run_next_test@d:\gecko\testing\xpcshell\head.js:1759:38
run@d:\gecko\testing\xpcshell\head.js:808:9
_do_main@d:\gecko\testing\xpcshell\head.js:245:6
_execute_test@d:\gecko\testing\xpcshell\head.js:596:5
@-e:1:1
With some debugging I learned that the message background task is somehow accessing the new attribute .origin
(which throws error when with system principal). But I'm not sure where and why exactly the access happens, as even with artificial MOZ_CRASH I can't really see the crash stack. Any idea, Nick?
Comment 6•3 days ago
|
||
(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #5)
Somehow the CI log doesn't have details, but local run shows it:
toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_experiments.js FAIL toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_experiments.js - xpcshell return code: 0 ERROR Unexpected exception TypeError: can't access property "args", infoMap.showAlert is undefined at D:/gecko/obj-aarch64-pc-windows-msvc/_tests/xpcshell/toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_experiments.js:189 test_backgroundtask_caps@D:/gecko/obj-aarch64-pc-windows-msvc/_tests/xpcshell/toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_experiments.js:189:15 async*_run_next_test/<@d:\gecko\testing\xpcshell\head.js:1759:22 _run_next_test@d:\gecko\testing\xpcshell\head.js:1759:38 run@d:\gecko\testing\xpcshell\head.js:808:9 _do_main@d:\gecko\testing\xpcshell\head.js:245:6 _execute_test@d:\gecko\testing\xpcshell\head.js:596:5 @-e:1:1
With some debugging I learned that the message background task is somehow accessing the new attribute
.origin
(which throws error when with system principal). But I'm not sure where and why exactly the access happens, as even with artificial MOZ_CRASH I can't really see the crash stack. Any idea, Nick?
Sure. What's happening is that the message
task mocks the alert mechanism, dumping to stdout instead; the failing test runs the task and parses that output. Around https://searchfox.org/mozilla-central/rev/25a38ac3b851b63e7d85a850940c354609e8126d/toolkit/components/backgroundtasks/BackgroundTask_message.sys.mjs#140-145, we're trying to serialize the alert datum naively, and making the getter fail for specific principals breaks the existing contract (which is that you can serialize the datum). You could strip the origin or otherwise work around it and I expect everything would work just fine. See how that works for you?
Assignee | ||
Comment 7•2 days ago
|
||
For now I made it never throw because I don't see an easy way to make JSON.stringify work without convoluting the implementation. I could make it return null but turns out it's not a thing. Bug 1966371.
![]() |
||
Comment 10•21 hours ago
|
||
This relanded with me as patch author. Can you back out and reland with you as author?
Assignee | ||
Comment 11•16 hours ago
|
||
First I'm not sure that's worth, a landed patch is more important to me than whose name is on it.
Second I'm not sherrif and can't backout?
Assignee | ||
Comment 12•16 hours ago
|
||
What happened btw? 🤔
Assignee | ||
Comment 13•15 hours ago
|
||
- This was already backed out once and still both landings used your name (Aryx), so nothing makes sure that the next landing will properly use my name. I pinged the right people and filed a bug.
Assignee | ||
Comment 14•13 hours ago
|
||
Okay, turns out I already had you as the author locally. The detailed log is gone as the initial patch was created months ago, but I'll request backout to make the blame less confusing.
Comment 15•11 hours ago
|
||
Comment 16•11 hours ago
|
||
Backed out as requested by krosylight.
Assignee | ||
Comment 17•11 hours ago
|
||
Thanks! Now let's hope the new landing goes with the right author.
Comment 18•11 hours ago
|
||
Comment 19•4 hours ago
|
||
bugherder |
Description
•