Move mozilla::net::ResolverMode into nsIDNSService and use it consistently
Categories
(Core :: Networking: DNS, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox87 | --- | fixed |
People
(Reporter: nhnt11, Assigned: nhnt11)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
|
(deleted),
text/x-phabricator-request
|
Details |
For some reason, the TRR service declares mMode as a uint32_t instead of nsIRequest::TRRMode or the wrapper nsHostResolver:ResolverMode (which is used fairly consistently elsewhere).
It'd be nice to explicitly type mMode for consistency. We are even setting the value from the ResolverMode constants already.
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 1•4 years ago
|
||
So... I took a poke at this and it turns out that TRRServiceBase.h ends up getting included when building UnifiedProtocols*.cpp due to the TRR service now living in the socket process and the way the IPC is implemented. This works because TRRServiceBase.h is exported into mozilla/net in netwerk/dns/moz.build. But we can't include nsHostResolver.h to get access to the ResolverMode name without also exporting nsHostResolver.h and everything that it includes into mozilla/net as well.
I think the right solution here would be to move the enum declaration into somewhere like nsIDNSService.idl (since GetCurrentTRRMode needs it) and use it from there.
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 2•4 years ago
|
||
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Comment 4•4 years ago
|
||
| bugherder | ||
Description
•