Open Bug 1696022 Opened 3 years ago Updated 1 year ago

Bookmark keyword searches using Hangul/Korean IME intermittently don't work

Categories

(Firefox :: Address Bar, defect, P3)

defect
Points:
3

Tracking

()

People

(Reporter: adw, Unassigned)

References

Details

(Keywords: papercut, Whiteboard: [snt-scrubbed][search-papercut])

STR

  1. Create a bookmark for https://dict.naver.com/search.nhn?dicQuery=%s with keyword d
  2. Open a private window
  3. Type d 하나 (d GKSK in ASCII)
  4. Observe that the heuristic result is correct (more or less, it's actually missing the second character): dict.naver.com: 하
  5. Press enter

Firefox does a Google search for d 하나 instead of correctly loading the bookmark. The problem doesn't happen in non-private windows.

I debugged this a little, and in both private and non-private windows, UrlbarInput.handleNavigation makes it all the way to the end, where it calls UrlbarUtils.getHeuristicResultFor, because there isn't a result up to that point. That doesn't seem right since there's clearly a heuristic result in the view. But regardless, in non-private windows we end up doing the right thing.

The only difference in private windows is that the query is stopped. UnifiedComplete is correctly called, but the query is stopped and pending is false before _matchPlacesKeyword can fetch a match.

The extra stop is due to this call:

      // TODO (Bug 1549936) this is necessary to avoid leaks in PB tests.
      this.manager.cancelQuery(queryContext);

I tested this in Windows using Nalgaeset IME (see bug 1679697 comment 0) but I don't know whether it's a problem with other IMEs, languages, or platforms.

As a workaround, you can press the left or right arrow key before pressing enter, as David notes in bug 1679697 comment 13. There are probably other workarounds too.

Just for information, I sometimes experience the non-private windows also gives google search result. I am not sure what triggers this behaviour, but one day firefox gives the correct result but some other day it gives google search.

You can see someone also mentioned this already in my previous bug report: bug 1678963, comment 4

Thanks, I'll update the bug summary.

It's possible there's some race condition with the cancelQuery call that affects both. I'm not actually sure why that comment mentions PB or why it's particular to PB since AFAICT the call happens regardless of the context's private status.

Summary: Bookmark keyword searches using Hangul/Korean IME don't work normally in private windows → Bookmark keyword searches using Hangul/Korean IME intermittently don't work

It's because the leak was only happening in PB windows. PB windows have this unfortunate thing where they tend to leak in mochitests more easily than other windows, and nobody still figured out why (it's intermittent and not trivial).

No longer blocks: qb-results-papercuts

Pressing Enter while Korean input system is at work (a box cursor is shown) in URL bar
always leads to the default engine.
Same behavior in nonprivate windows, too.

Tested on MSWin10.

A possible next step for this is to test removing the cancel query statement and the running the test on TreeHerder to see if the leaks are still happening. If they aren't, it would likely solve this issue.

Whiteboard: [snt-scrubbed][search-papercut]
See Also: → 1549936
You need to log in before you can comment on or make changes to this bug.