Closed Bug 1088050 Opened 10 years ago Closed 9 years ago

Need a pref to disable searching for single-word input in the URL bar

Categories

(Core :: DOM: Navigation, defect)

x86_64
All
defect
Not set
normal
Points:
5

Tracking

()

RESOLVED FIXED
mozilla36
Iteration:
37.1
Tracking Status
firefox35 --- fixed
firefox36 --- fixed

People

(Reporter: insiac, Assigned: Gijs)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

Implementation of bug 693808 changes the behavior, when comparing to the past implementation.

The user should be able to have an option to revert to the original behavior.
Usage example: In environment with hundreds of single word/keyword domains( ex. http://server01, http://server02, http://server03 …), adding all of them to the white-list is, at the very least, difficult.

User should be able to disable the “search and display results first, if DNS revolution succeeds suggest the URL” and revert back to “wait for DNS resolution, and only if it fails display search results”
Blocks: 693808
Component: Document Navigation → General
Product: Core → Firefox
(In reply to insiac from comment #0)
> The user should be able to have an option to revert to the original behavior.
> Usage example: In environment with hundreds of single word/keyword domains(
> ex. http://server01, http://server02, http://server03 …), adding all of them
> to the white-list is, at the very least, difficult.

Can you explain more about this environment? I've never seen one. I've lived on N0,000-machine university intranets, and had access to various other bits over the years, but the 99% usecase (for having non-TLD'd hosts) here in practice seems to be aliases for localhost (in /etc/hosts or equivalent), home routers, and a limited set (<5-10) shared intranet hosts in office/gov't/uni environments. I'd like to understand better in what circumstances people rely on having "hundreds" of individual hosts with no domains.

Clicking the "yes, take me to ..." button automatically adds the host to the whitelist, so for anything up to 10-20 hosts, it seems tedious but workable to me, especially if done on an as-needed basis.

The short-term workaround for the hundreds/thousands case would be disabling keyword.enabled.
Flags: needinfo?(insiac)
Summary: single word url - enable/disable order of events → Need a pref to disable searching for single-word input in the URL bar
Component: General → Document Navigation
Product: Firefox → Core
bz: sorry for moving this back; I didn't realize you moved it to fx::general (thank bugzilla's theme for that, I need to file a bug on that...). I do think that any such pref would have to live and be respected by nsURIFixup, though, which is still in docshell until we get bug 1057531 fixed... if you disagree, feel free to move back to fx::location bar or something.
(In reply to :Gijs Kruitbosch from comment #1)
> (In reply to insiac from comment #0)
> > The user should be able to have an option to revert to the original behavior.
> > Usage example: In environment with hundreds of single word/keyword domains(
> > ex. http://server01, http://server02, http://server03 …), adding all of them
> > to the white-list is, at the very least, difficult.
> 
> Can you explain more about this environment? I've never seen one. I've lived
> on N0,000-machine university intranets, and had access to various other bits
> over the years, but the 99% usecase (for having non-TLD'd hosts) here in
> practice seems to be aliases for localhost (in /etc/hosts or equivalent),
> home routers, and a limited set (<5-10) shared intranet hosts in
> office/gov't/uni environments. I'd like to understand better in what
> circumstances people rely on having "hundreds" of individual hosts with no
> domains.
> 
> Clicking the "yes, take me to ..." button automatically adds the host to the
> whitelist, so for anything up to 10-20 hosts, it seems tedious but workable
> to me, especially if done on an as-needed basis.
> 
> The short-term workaround for the hundreds/thousands case would be disabling
> keyword.enabled.

Small to mid-size enterprise infrastructure. the hosts are defined in DNS with non-TLD domains. 
The clients hosts have their DNS settings configured to include search suffixes, which allows us to specify non-FQDN (ie. just the hostname) to access the targeted machines. 
Whether the hostnames are defined in the host file or queried on the DNS servers should not matter. In ether case there should be an option for single keyword URL to be accessed directly and not queried with a search engine (as the first step). This was the behavior that was in place up until this point, and an option to allow the user to choose to maintain this behavior is desirable. 

Additional problem is that every time a new client machine is used, the hosts would have to be re-added. if this option was available, with a single modification, this problem would be avoided.

The recommendation of disabling keyword.enabled is a workaround, but it disables other features (search/bookmark keyword shortcuts), which are in use, therefore making it unusable.
Flags: needinfo?(insiac)
(In reply to insiac from comment #3)
> (In reply to :Gijs Kruitbosch from comment #1)
> > (In reply to insiac from comment #0)
> > > The user should be able to have an option to revert to the original behavior.
> > > Usage example: In environment with hundreds of single word/keyword domains(
> > > ex. http://server01, http://server02, http://server03 …), adding all of them
> > > to the white-list is, at the very least, difficult.
> > 
> > Can you explain more about this environment? I've never seen one. I've lived
> > on N0,000-machine university intranets, and had access to various other bits
> > over the years, but the 99% usecase (for having non-TLD'd hosts) here in
> > practice seems to be aliases for localhost (in /etc/hosts or equivalent),
> > home routers, and a limited set (<5-10) shared intranet hosts in
> > office/gov't/uni environments. I'd like to understand better in what
> > circumstances people rely on having "hundreds" of individual hosts with no
> > domains.
> > 
> > Clicking the "yes, take me to ..." button automatically adds the host to the
> > whitelist, so for anything up to 10-20 hosts, it seems tedious but workable
> > to me, especially if done on an as-needed basis.
> > 
> > The short-term workaround for the hundreds/thousands case would be disabling
> > keyword.enabled.
> 
> Small to mid-size enterprise infrastructure. the hosts are defined in DNS
> with non-TLD domains. 
> The clients hosts have their DNS settings configured to include search
> suffixes, which allows us to specify non-FQDN (ie. just the hostname) to
> access the targeted machines. 
> Whether the hostnames are defined in the host file or queried on the DNS
> servers should not matter. In ether case there should be an option for
> single keyword URL to be accessed directly and not queried with a search
> engine (as the first step). This was the behavior that was in place up until
> this point, and an option to allow the user to choose to maintain this
> behavior is desirable.

And you have hundreds of these in small- to midsize enterprises? Maybe we have a different definition of small- to midsize...

> Additional problem is that every time a new client machine is used, the
> hosts would have to be re-added. if this option was available, with a single
> modification, this problem would be avoided.

This could be set up in the default deployment scripts/profile for a machine. If an enterprise seriously has hundreds of servers, surely they don't sit someone in front of every new desktop machine they deploy to manually set up all the software? This is what unattended install scripts and Firefox's default profile stuff exists for.

> The recommendation of disabling keyword.enabled is a workaround, but it
> disables other features (search/bookmark keyword shortcuts), which are in
> use, therefore making it unusable.

This is not entirely true. It disables default search from the address bar, but it does not disable bookmark keywords.

The reason I'm pushing back is that we already have a bundle of prefs that control behaviour and I personally at least am loathe to add more and continue exponentially expanding the number of ways this part of the code reacts to input (which is in itself a hard enough problem without all the prefs and OS-specific things interfering).
(In reply to :Gijs Kruitbosch from comment #4)
> (In reply to insiac from comment #3)
> > (In reply to :Gijs Kruitbosch from comment #1)
> > > (In reply to insiac from comment #0)
> > > > The user should be able to have an option to revert to the original behavior.
> > > > Usage example: In environment with hundreds of single word/keyword domains(
> > > > ex. http://server01, http://server02, http://server03 …), adding all of them
> > > > to the white-list is, at the very least, difficult.
> > > 
> > > Can you explain more about this environment? I've never seen one. I've lived
> > > on N0,000-machine university intranets, and had access to various other bits
> > > over the years, but the 99% usecase (for having non-TLD'd hosts) here in
> > > practice seems to be aliases for localhost (in /etc/hosts or equivalent),
> > > home routers, and a limited set (<5-10) shared intranet hosts in
> > > office/gov't/uni environments. I'd like to understand better in what
> > > circumstances people rely on having "hundreds" of individual hosts with no
> > > domains.
> > > 
> > > Clicking the "yes, take me to ..." button automatically adds the host to the
> > > whitelist, so for anything up to 10-20 hosts, it seems tedious but workable
> > > to me, especially if done on an as-needed basis.
> > > 
> > > The short-term workaround for the hundreds/thousands case would be disabling
> > > keyword.enabled.
> > 
> > Small to mid-size enterprise infrastructure. the hosts are defined in DNS
> > with non-TLD domains. 
> > The clients hosts have their DNS settings configured to include search
> > suffixes, which allows us to specify non-FQDN (ie. just the hostname) to
> > access the targeted machines. 
> > Whether the hostnames are defined in the host file or queried on the DNS
> > servers should not matter. In ether case there should be an option for
> > single keyword URL to be accessed directly and not queried with a search
> > engine (as the first step). This was the behavior that was in place up until
> > this point, and an option to allow the user to choose to maintain this
> > behavior is desirable.
> 
> And you have hundreds of these in small- to midsize enterprises? Maybe we
> have a different definition of small- to midsize...
> 
> > Additional problem is that every time a new client machine is used, the
> > hosts would have to be re-added. if this option was available, with a single
> > modification, this problem would be avoided.
> 
> This could be set up in the default deployment scripts/profile for a
> machine. If an enterprise seriously has hundreds of servers, surely they
> don't sit someone in front of every new desktop machine they deploy to
> manually set up all the software? This is what unattended install scripts
> and Firefox's default profile stuff exists for.
>
unfortunately there is a "separation of responsibilities" and some parties don't play nice. not to mention it adds an extra layer of complexity to the deployment.
> 
> > The recommendation of disabling keyword.enabled is a workaround, but it
> > disables other features (search/bookmark keyword shortcuts), which are in
> > use, therefore making it unusable.
> 
> This is not entirely true. It disables default search from the address bar,
> but it does not disable bookmark keywords.
>
you are correct, in my quick test i made an error. this might be a more viable workaround then i initial believed.
> 
> The reason I'm pushing back is that we already have a bundle of prefs that
> control behaviour and I personally at least am loathe to add more and
> continue exponentially expanding the number of ways this part of the code
> reacts to input (which is in itself a hard enough problem without all the
> prefs and OS-specific things interfering).
>
If you believe that additional pref is not something that is feasible, maybe there is another option . In the bug 693808, there was a reference to chrome, and mimicking it's behavior. in chrome, if a keyword is terminated with a  "/" the it is the keyword is treated as a URL, otherwise a search keyword.
ex: 
server1 -> search for server1
server1/ -> host server1 
This is a LESS DESIRABLE option, as it still doesn't give an option of revert to legacy behavior.

I performed one more test: 
1) URL entered: server1:80
2) host server1 is connected to and page loads, the address bar entry is changed to -> server1
3) trying to modify the URL requires re-typing the ":80"
Same thing happens when the initial URL is typed as "http://server1". On page load, the "http://" is removed, and editing the URL requires reentering it.
In the previous versions(and if the perf was provided, this behavior would be selectable) this was not an issue, and the updated(stripped) URL were easily modifiable, without the need to re-type the removed sections, because the browser did not automatically redirect to the search result page.
I just wanted to add another voice to this issue. I can describe the environment that I administer, which is a small to medium-sized hospital (~1000-1500 staff). We have hundreds of (500+) internal web pages that are generated by everything from medical devices, to printers, to IT back-end infrastructure (routers, switches, APs) as well as the "standard" websites (intranet, payroll, scheduling, etc).

The UI to "ask once" for override is not feasible to use in our environment. A single nurse might need to log into several medical devices today when working on one unit, and then an entirely new set of devices tomorrow from a different unit. It would effectively take months for each individual user to "override" all of the pages that they need to visit. 

Again, I thought I would add insight (since it was requested above) to the type of environments that need this issue to be addressed properly. I would find it difficult to believe that our organization is the only one to find this behavior unworkable.

Either of the proposed solutions (a configurable preference, or the trailing forward slash, or ideally both) would resolve this for us.
Sigh. This was harder than I anticipated, which makes me more reluctant to do this, but this seems to affect a significant number of people. Blair, I'm feedback?ing you because I wonder how this jives with the 'require a whitelist' bits, partly because I don't remember why we have that...
Attachment #8523567 - Flags: review?(bugs)
Attachment #8523567 - Flags: feedback?(bmcbride)
Assignee: nobody → gijskruitbosch+bugs
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
See Also: → 1083634
Marco, can you add this?
Iteration: --- → 36.3
Points: --- → 5
Flags: qe-verify-
Flags: needinfo?(mmucci)
Flags: in-testsuite+
Flags: firefox-backlog+
Added to IT 36.3
Flags: needinfo?(mmucci)
Comment on attachment 8523567 [details] [diff] [review]
add a pref to disable search for single-word hosts,

Review of attachment 8523567 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to :Gijs Kruitbosch from comment #8)
> Blair, I'm
> feedback?ing you because I wonder how this jives with the 'require a
> whitelist' bits, partly because I don't remember why we have that...

Essentially, to make the fixup less smart. UnifiedComplete wants to do the work, and have the fixup be dumb and predictable.

I think we should be able to make this a lot simpler if we just use the whitelist stuff actually. Wouldn't it be enough to just make IsDomainWhitelisted() always return true if the relevant pref is set? Or a I missing something?
Attachment #8523567 - Flags: feedback?(bmcbride) → feedback+
(In reply to Blair McBride [:Unfocused] from comment #11)
> Comment on attachment 8523567 [details] [diff] [review]
> add a pref to disable search for single-word hosts,
> 
> Review of attachment 8523567 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> (In reply to :Gijs Kruitbosch from comment #8)
> > Blair, I'm
> > feedback?ing you because I wonder how this jives with the 'require a
> > whitelist' bits, partly because I don't remember why we have that...
> 
> Essentially, to make the fixup less smart. UnifiedComplete wants to do the
> work, and have the fixup be dumb and predictable.
> 
> I think we should be able to make this a lot simpler if we just use the
> whitelist stuff actually. Wouldn't it be enough to just make
> IsDomainWhitelisted() always return true if the relevant pref is set? Or a I
> missing something?

ISTR it's used by the "require whitelist" bit, and I didn't want to change that behaviour, expecting unintended consequences...
So one would need to know about this rather hidden pref. Is there really no better options?
Like that 'ends with "/" is treated as a host'.
Or is the plan to have some UI for the pref (I don't consider about:config as an UI which any user should use)
Comment on attachment 8523567 [details] [diff] [review]
add a pref to disable search for single-word hosts,

>+      rv = Preferences::AddBoolVarCache(&sDNSFirstForSingleWords,
>+                                        "browser.fixup.dnsfirstforsinglewords",
The pref name is rather hard to read. Perhaps
browser.fixup.dns_first_for_single_words

>+                                        sDNSFirstForSingleWords);
>+      MOZ_ASSERT(NS_SUCCEEDED(rv), "Failed to observe \"browser.fixup.dnsfirstforsinglewords\"");
And change it here too.

>+
>       rv = Preferences::AddBoolVarCache(&sFixupKeywords, "keyword.enabled",
>                                         sFixupKeywords);
>       MOZ_ASSERT(NS_SUCCEEDED(rv), "Failed to observe \"keyword.enabled\"");
>       sInitializedPrefCaches = true;
>     }
> 
>     // Fix up common scheme typos.
>     if (sFixTypos && (aFixupFlags & FIXUP_FLAG_FIX_SCHEME_TYPOS)) {
> 
>         // Fast-path for common cases.
>@@ -1061,37 +1067,38 @@ nsDefaultURIFixup::KeywordURIFixup(const
> 
>     // If there are only colons and only hexadecimal characters ([a-z][0-9])
>     // enclosed in [], then don't do a keyword lookup
>     if (looksLikeIpv6) {
>         return NS_OK;
>     }
> 
>     nsresult rv = NS_OK;
>     // We do keyword lookups if a space or quote preceded the dot, colon
>     // or question mark (or if the latter were not found)
>-    // or when the host is the same as asciiHost and there are no
>-    // characters from [a-z][A-Z]
>     if (((firstSpaceLoc < firstDotLoc || firstQuoteLoc < firstDotLoc) &&
>          (firstSpaceLoc < firstColonLoc || firstQuoteLoc < firstColonLoc) &&
>-         (firstSpaceLoc < firstQMarkLoc || firstQuoteLoc < firstQMarkLoc)) || firstQMarkLoc == 0 ||
>-        (isValidAsciiHost && isValidHost && !hasAsciiAlpha &&
>-         host.EqualsIgnoreCase(asciiHost.get()))) {
>-

>+         (firstSpaceLoc < firstQMarkLoc || firstQuoteLoc < firstQMarkLoc)) || firstQMarkLoc == 0) {
>+        rv = TryKeywordFixupForURIInfo(aFixupInfo->mOriginalInput, aFixupInfo, aPostData);
>+    // ... or when the host is the same as asciiHost and there are no
>+    // characters from [a-z][A-Z]
>+    } else if (isValidAsciiHost && isValidHost && !hasAsciiAlpha && !sDNSFirstForSingleWords &&
>+               host.EqualsIgnoreCase(asciiHost.get())) {
>         rv = TryKeywordFixupForURIInfo(aFixupInfo->mOriginalInput, aFixupInfo, aPostData);
So you want !sDNSFirstForSingleWords here so that we enter the next else-if if sDNSFirstForSingleWords is true right?
Please add a comment about it.


>+const kForceHostLookup = "browser.fixup.dnsfirstforsinglewords";
This should use the other 

>+pref("browser.fixup.dnsfirstforsinglewords", false);
And here.


But I think relying on some hidden pref is very suboptimal.
Could we take this patch, but also have the "end with '/'" behavior?
Attachment #8523567 - Flags: review?(bugs) → review+
(In reply to Olli Pettay [:smaug] from comment #13)
> So one would need to know about this rather hidden pref. Is there really no
> better options?
> Like that 'ends with "/" is treated as a host'.

Yes, that's bug 1083634.
(In reply to Olli Pettay [:smaug] from comment #14)
> Comment on attachment 8523567 [details] [diff] [review]
> add a pref to disable search for single-word hosts,
> 
> >+      rv = Preferences::AddBoolVarCache(&sDNSFirstForSingleWords,
> >+                                        "browser.fixup.dnsfirstforsinglewords",
> The pref name is rather hard to read. Perhaps
> browser.fixup.dns_first_for_single_words
> 
> >+                                        sDNSFirstForSingleWords);
> >+      MOZ_ASSERT(NS_SUCCEEDED(rv), "Failed to observe \"browser.fixup.dnsfirstforsinglewords\"");
> And change it here too.
> 
> >+
> >       rv = Preferences::AddBoolVarCache(&sFixupKeywords, "keyword.enabled",
> >                                         sFixupKeywords);
> >       MOZ_ASSERT(NS_SUCCEEDED(rv), "Failed to observe \"keyword.enabled\"");
> >       sInitializedPrefCaches = true;
> >     }
> > 
> >     // Fix up common scheme typos.
> >     if (sFixTypos && (aFixupFlags & FIXUP_FLAG_FIX_SCHEME_TYPOS)) {
> > 
> >         // Fast-path for common cases.
> >@@ -1061,37 +1067,38 @@ nsDefaultURIFixup::KeywordURIFixup(const
> > 
> >     // If there are only colons and only hexadecimal characters ([a-z][0-9])
> >     // enclosed in [], then don't do a keyword lookup
> >     if (looksLikeIpv6) {
> >         return NS_OK;
> >     }
> > 
> >     nsresult rv = NS_OK;
> >     // We do keyword lookups if a space or quote preceded the dot, colon
> >     // or question mark (or if the latter were not found)
> >-    // or when the host is the same as asciiHost and there are no
> >-    // characters from [a-z][A-Z]
> >     if (((firstSpaceLoc < firstDotLoc || firstQuoteLoc < firstDotLoc) &&
> >          (firstSpaceLoc < firstColonLoc || firstQuoteLoc < firstColonLoc) &&
> >-         (firstSpaceLoc < firstQMarkLoc || firstQuoteLoc < firstQMarkLoc)) || firstQMarkLoc == 0 ||
> >-        (isValidAsciiHost && isValidHost && !hasAsciiAlpha &&
> >-         host.EqualsIgnoreCase(asciiHost.get()))) {
> >-
> 
> >+         (firstSpaceLoc < firstQMarkLoc || firstQuoteLoc < firstQMarkLoc)) || firstQMarkLoc == 0) {
> >+        rv = TryKeywordFixupForURIInfo(aFixupInfo->mOriginalInput, aFixupInfo, aPostData);
> >+    // ... or when the host is the same as asciiHost and there are no
> >+    // characters from [a-z][A-Z]
> >+    } else if (isValidAsciiHost && isValidHost && !hasAsciiAlpha && !sDNSFirstForSingleWords &&
> >+               host.EqualsIgnoreCase(asciiHost.get())) {
> >         rv = TryKeywordFixupForURIInfo(aFixupInfo->mOriginalInput, aFixupInfo, aPostData);
> So you want !sDNSFirstForSingleWords here so that we enter the next else-if
> if sDNSFirstForSingleWords is true right?
> Please add a comment about it.

If sDNSFirstForSingleWords is true, it'll enter the next block and return NS_OK with a no-op. I guess I can move the check inside the block in order to return immediately, which is probably clearer.

However... per comment #11 / comment #12 I wonder if it isn't easier to just update IsDomainWhitelisted to always return true if the pref is set. Not sure that's possible though. Blair?
Flags: needinfo?(bmcbride)
Pref name updated, modifying IsDomainWhitelisted instead. Note that (a) I didn't want to make things subject to the whitelist thing that weren't before (ie this pref shouldn't affect the fact that 'foo bar baz' causes a search - which meant leaving the first 'if' block untouched), (b) I wanted to fix the cases that we changed that currently ignore the whitelist (hostnames with no alphabet chars, basically, like broken ipv6 addresses and other bogus things) to obey this pref (the bit I split off from the first if condition), (c) I wanted to adjust the require_whitelist thing per discussion with Blair. This makes the actual behaviour... finnicky. I think this should basically do what one would intuitively expect, although cases with just '?: and variations on that theme that trigger one or the other if may yield surprises. I actually suspect that the most efficient way to give feedback on this change is to carefully review the test changes in the patch.
Attachment #8524997 - Flags: review?(bugs)
Attachment #8524997 - Flags: feedback?(bmcbride)
Attachment #8523567 - Attachment is obsolete: true
Comment on attachment 8524997 [details] [diff] [review]
add a pref to disable search for single-word hosts,

I still think / ending should be treated as if 
browser.fixup.dns_first_for_single_words was true.
Attachment #8524997 - Flags: review?(bugs) → review+
(In reply to Olli Pettay [:smaug] from comment #18)
> Comment on attachment 8524997 [details] [diff] [review]
> add a pref to disable search for single-word hosts,
> 
> I still think / ending should be treated as if 
> browser.fixup.dns_first_for_single_words was true.

Yes, as noted, bug 1083634 deals with that - but I don't think that's enough, considering the usecases given by various folks, so 1 step at a time.

Unfortunately I have some other things that need finishing for this week, and so I won't get to bug 1083634 right now - but I hope to get to that issue in the two weeks after that (though... portland...). Please feel free to ping me if there is no action there by Dec 9. 

(clearing Blair's needinfo considering the f? is now there)
Flags: needinfo?(bmcbride)
Iteration: 36.3 → 37.1
Comment on attachment 8524997 [details] [diff] [review]
add a pref to disable search for single-word hosts,

Review of attachment 8524997 [details] [diff] [review]:
-----------------------------------------------------------------

Apologies for the conference-induced lag.

Also: I hate this code.
Attachment #8524997 - Flags: feedback?(bmcbride) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/b16c0306ec57
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla36
Comment on attachment 8524997 [details] [diff] [review]
add a pref to disable search for single-word hosts,

Approval Request Comment
[Feature/regressing bug #]: 693808
[User impact if declined]: can't turn off dot-less-host search things
[Describe test coverage new/current, TBPL]: has extensive test coverage (in fact, that's the biggest part of this patch)
[Risks and why]: Obviously it's not early in beta anymore. However, this has baked for a good amount of time on aurora and nightly with no issues reported, is a self-contained change, and has automated tests, so the risk is very low, IMO.
[String/UUID change made/needed]: nope
Attachment #8524997 - Flags: approval-mozilla-beta?
Comment on attachment 8524997 [details] [diff] [review]
add a pref to disable search for single-word hosts,

thanks for the extensive test coverage, let's uplift today to get into beta 6.
Attachment #8524997 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Depends on: 1181082
You need to log in before you can comment on or make changes to this bug.