[Nightly] Private window search using context menu uses default engine instead of engine selected for private window

[Brave-Matt]

Description

On Brave Nightly (1.75.112) there is an error with the default search engines — when Nightly private window engine is selected, selecting text and using the Search ____ for… option in the context menu searches using the default engine, not the one set to be used in Nightly. Note that this occurs regardless of which Search engines you have set as the defaults:

Screen.Recording.2024-12-19.at.10.19.03.AM.mov

Steps to reproduce

1. Set normal window Search engine to Brave
2. Set private window search engine to DDG
3. Open private window, select some text and select Search DDG for... option from context menu

Actual result

Text is searched on the engine set for use in the normal window, not private window

Expected result

Selected text should be searched using the default engine set to be used for private windows

Reproduces how often

Easily reproduced

Brave version (brave://version info)

Always

Channel information

• release (stable)
• beta
• nightly

Reproducibility

• with Brave Shields disabled
• with Brave Rewards disabled
• in the latest version of Chrome

Miscellaneous information

No response

[diracdeltas]

not the one set to be used in Nightly

I think you mean "the one set to be used in Private Windows". confirmed it works fine in beta.

Anyway this seems like a high priority so I marked it p2

[rebron]

@emerick Maybe a bug from this fix brave/brave-core#26675

[emerick]

@cdesouza-chromium I think this is caused by #42339. In @simonhong's fix for #9239, he mentions the following in his commit message:

Use temporal AutocompleteClassifier to get proper navigation url

To get proper selection navigation url for profile, use tempral
AutocompleteClassfier. We can't use AutocompleteClassifierFactory
for this because AutocompleteClassifierFactory doesn't create service
for otr profile. But we need different navigation url for OTR profile.

Not sure if there is a better workaround we can apply for the dangling pointer issue, but if not we should revert this for now.