In the Quantum Bar it's usually the urlbar code that decides whether a search
string should be visited or searched. if dns_first_for_single_words is set,
we can't make a final decision, because that depends on a dns lookup. For now
we don't want to duplicate the docshell code, also because we must keep the
old behavior functioning for cases where the urlbar value is set without input.
Similarly, when the docshell decides to search for a single word host, and a
dns lookup resolves it, it also shows a prompt asking the user if he meant to
visit it instead of searching. Because the urlbar skips the docshell decision
making, we must manually call the fixup prompt code from the urlbar.
Differential Revision: https://phabricator.services.mozilla.com/D45743
The idea here is that we avoid updating all site data in SiteDataManager.jsm
just for checking a single host/origin and that we optimize performance by prioritizing
the most common data type (cookies) and synchronous lookups (AppCache) and returning
early if any data was found.
We will still refresh the site data list for clearing once the user clicks on "Clear Site Data".
Differential Revision: https://phabricator.services.mozilla.com/D42800
We need to start engagement event recording when the view opens due to `openViewOnFocus`. We already do for mouse clicks since we call `engagementEvent.start` from `_on_mousedown`. But we don't for the Ctrl/Command-L key shortcut. The shortcut command calls `openLocation` in browser.js, which calls `gURLBar.startQuery` but not `engagementEvent.start`.
Every time we call `engagementEvent.start`, we do it before calling `input.startQuery`. The one exception is in `input._on_drop` because there we just handle the dropped value directly instead of starting a new query with it.
The inverse is also mostly true, i.e., every time we call `input.startQuery`, we also call `engagementEvent.start`. The three exceptions are: in UITour (where it looks like we should be calling `urlbar.search` instead), in `UrlbarInput` after picking a keyword offer result, and in `openLocation` in browser.js (mentioned above). So really the only valid place is after picking a keyword entry.
So, it makes sense to move `engagementEvent.start()` into `input.startQuery` so that callers don't have to call it. I added an `event` param to `startQuery`, since `engagementEvent.start` needs one. I considered removing that need. It's possible, but then we would need a way to avoid calling `engagementEvent.start` in the keyword offer case, so `startQuery` would need something like a `suppressEngagementEvent` param. `event` basically functions as that, so I left it.
Another thing to point out about this patch is that I chose to record a "typed" value when the pageproxystate is invalid and the view opens due to `openViewOnFocus`. The view does not show the user's top sites in that case, so "topsites" seems wrong.
Differential Revision: https://phabricator.services.mozilla.com/D42749
This patch modify the way how tooltip works on the tracking protection
icon. We use <tooltip> instead of 'tooltiptext' attribute in order to
limit the width of the tooltip in 500px.
Differential Revision: https://phabricator.services.mozilla.com/D40416
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
