When URL bar gets focus, language should switch to English




16 years ago
10 years ago


(Reporter: eyalroz, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)



(2 attachments)



16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030502
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030502

AFAIK all URLs contain only RTL latin text; now, although LTR text can be
encoded using %XX notation, it's never (again AFAIK) the case that a URL starts
with %XX and it is rarely the case that people wish to enter RTL text (to be
encoded into the URL) directly in the URL bar. I therefore suggest that whenever
the URL bar gets keyboard focus, the input direction will be set to LTR if it
had been RTL. This means different things for different platforms, of course.

Reproducible: Always

Steps to Reproduce:
In principle I agree with what I think you mean, but IRIs are going to
complicate the issue, and the URLbar can also be used to enter local filespecs,
which I think can begin with RTL characters on some platforms.
Ever confirmed: true

Comment 2

16 years ago
But even local filespecs are something like "file://whatever", or "C:\dir\file"
or "/home/myself/file" . I wonder if there really are exceptions to this rule? I
always get frustrated when I find I've inadvertantly typed '''хтннткчхбнц
instead of www.google.com .

Of course, this could be made an option instead of a fixed behavior.

Comment 3

16 years ago
As far as I can understand from the ivrix and w3c-i18n mailing list, IRIs will
still start with roman characters- or am I missing something?
>I wonder if there really are exceptions to this rule?

On Mac OS 9.x and below, path formats are Volume:folder:file
on those system, the volume name can be Hebrew or Arabic. However, mozilla does
not have an official os9 build anymore.

In theory osx might support the same thing, however:
1) it is too buggy to use at the moment, and it does look like it is going to be
fixed soon.
2) even after it is fixed, you can still use unix style path

Therefore, imo, unless BeOS is completely diffrent (prog?), we should not set
the direction to rtl, as the platforms we support start the address (local) with
a lrt character anyway.

Comment 4

16 years ago
It's the same with BeOS. The  address bars of Tracker and Net+ are always LTR,
even if a volume name is in Hebrew. This is expected of course, BeOS uses the
Unix standard - "/" so no file-system path ever starts with a letter.
Furthermore, BeOS has no built-in RTL support at all (but thanks to Mozilla,
this is not much of an issue).

I don't quite understand your request, Eyal, isn't this already the default
behavior? any steps to reproduce the problem?


Comment 5

16 years ago
No, prognathous, this is not the default behavior! On Win2k, and probably on
other platforms too, If the input direction is let to RTL (and the language to
some RTL language like Hebrew or Arabic), and you click the URL bar and start
typing, you get Hebrew or Arabic text. This always happens. You don't need any
special circumstances to reproduce the problem.

Comment 6

16 years ago
Created attachment 122986 [details]
rtl page - address bar remains ltr

I tested this under WinXP with v1.3, and the problem doesn't seem to have
anything to do with directionality. See attached screenshot.

What you request, if I may rephrase, is for the *input language* to change
automatically from non-latin to latin. Now, although I can see why this may be
beneficial in this specific case, I personally hate it when Mozilla (on Win32)
messes around with my input language. See Bug 179377 and Bug 162242 for more
details about why this "feature" should be removed completely.


Comment 7

16 years ago
Adding neokuwait@hotpop.com (Thamer) to cc, as this RFE is directly related to
his/hers Bug 162242 ("BiDi: Text input is auto switching between Arabic/Hebrew
and English").


PS. that should have been "messes with my input language" rather than "messes
around with my input language" ;-)

Comment 8

16 years ago
prognathous, you are right and I hereby apologize for mis-reporting the problem.
It is indeed the issue of input language, not input direction. The direction is
unimportant, the language is. I claim it's better to change the language to a
Latin language when the URL bar gets focus.

I realize by reading bug 162242 that there are some mis-switches between
keyboard languages - but those are orthogonal to what I'm talking about! It's
not as though, in order to always have Latin language in the URL bar, various
switches are implemented which have adverse (side-)effects - the problem I'm
reporting is not addressed. In fact, Thamer's original report listed the fact
that he gets Arabic in the URL bar as something undesirable.

So I think the solution should be a serious examination of the language
switching mechanism, and its re-implementation so that switching does occur -
but only when it can be reasonably expected, like a switch to Latin or English
when keyboard focus moves to the URL bar.
Summary: direction of text input in the URL bar upong getting keyboard focus → (possibility of changing) text input language in the URL bar upon getting keyboard focus

Comment 9

16 years ago
Ok, yeah this makes more sense. I've run into it (on Windows 2000, but not BeOS)
and it does annoy me a bit. I'll load a random page that happened to have Hebrew
or Arabic on it and then I'll focus the urlbar and start typing a new url (which
should be English) and instead I'll get what I'd lovingly call gibberish :).

The problem here is that IRI at least past a certain point would probably allow
what I typed so just switching over might upset someone eventually.  -- But as
an American I wouldn't mind being switched to English.

I think it would be reasonable for us to make the urlbar always check the input
locale and ignore the page autosensing (which to my knowledge can't be
disabled). Any user who wants to use IRIs would then be required to change the
input locale for the app/os, which seems perfectly reasonable to me.

Comment 10

16 years ago
Is this something we want to fix for all platforms or only for Windows?

Comment 11

16 years ago
> Is this something we want to fix for all platforms or only for Windows?

This request now only applies to Windows. As far I know, Mozilla never changes
the input language on any other OS (which is a good thing).

Shouldn't there be a meta bug for tracking the automatic switching of input
languages? IMHO, Mozilla's implementation requires a major redesign. Currently,
users (on Windows) would be much better off if we disable it completely, at
least until an alternative redesign offers something they would actually find
useful and not annoying. 


Comment 12

16 years ago
Umm, prognathous, the very reason I filed this bug was because I think there
_should_ be switching. The problem is both lack of switching when it is needed
and (in other bugs) switches when they're not needed.
A clarification: quite apart from the question whether there should be language
switching at all, this is definitely a bug, and should not happen according to
the way that the language switching was designed.

Positioning the caret in the URL bar should almost always cause a switch to
left-to-right language. The only exceptions would occur if there were already
right-to-left characters in the URL bar, for example if the URL bar contained an
IRI with a right-to-left element and the user clicked in that element. For
details of the expected behaviour see
Assignee: mkaply → smontagu

Comment 14

16 years ago
In my experience, the problem in comment 9 is not reproducible by just loading a
page with Hebrew or Arabic, but you have to actually click on the document's
area or select some RTL text or image before the switch occurs. So basically the
switching is *not* happening at the URL bar, but probably before that. I have
previously reported this unexpected behavior on bug 162242.

Does the above guidelines link say anything about empty text widgets? Currently,
Mozilla is constantly trying to match the input language with the document's
direction. Thus it becomes increasingly annoying while filling an RTL form with
LTR data (or vice-versa), which is rather a common thing to do.
The guidelines say that all text widgets are considered to have a dummy
character in the base direction at the beginning and the end, so clicking in an
empty left-to-right text widget should be treated exactly the same as clicking
between two left-to-right characters. Right now it isn't, and that is the bug.

I agree that entering RTL data in an LTR form and vice versa will be
inconvenient even when the bug is fixed, but that discussion belongs more in bug
Priority: -- → P4
Target Milestone: --- → Future

Comment 16

16 years ago
What good are these language-switching guidelines, if they are inconsistent with
what users expect from their OS? I don't see the logic in following a theory
that breaks existing UI consistency. 

Ever wondered why this bug doesn't happen with Internet Explorer or Safari?
simple, both Windows and Mac OS do not include any automatic language switching.
In fact, I couldn't find this novel idea mentioned in Microsoft'S and Apple's
Interface Guidelines.

Eyal, here are a couple of (rather ugly) workarounds for you:

1. Drag-select the URL with the mouse, from end to start.
2. F6 -> RightArrow -> LeftArrow -> Esc

In both cases, the input method should change to English.

Regardless of UI consistency, even by its own standards, this "feature" is
broken in Mozilla. Wouldn't it be better to at least provide a pref for
disabling it until a better implementation is available?


Comment 17

16 years ago
Ah, but the whole point of filing this bug is avoiding the need for extra
keypresses to ensure LTR direction in the URL bar...

Comment 18

16 years ago
That's why the first workaround makes more sense...

As for the second suggestion, the rational (compared to Alt+Shift) is to always
switch the input method to English without having to first check the currently
selected one (via the language icon or the hard-to-see caret direction). This is
exactly the opposite of what RightAlt+Shift does - it always switches the input
method to *Hebrew*. Therefore, a third workaround could be: RightAlt+Shift ->

As I said, this is ugly compared to the simple (yet effective) way that other
browsers handle language switching.


Comment 19

16 years ago
Come to think about it, if we do use automatic language switching for the URL
bar, then the original input language should be restored when focus is returned
to the page.

BTW, Eyal, you might want to change the title of this bug to something that is
easier to find and understand, such as: "When the URL bar gets focus, the
language should switch to English". Note that this request doesn't really have
anything to do with the keyboard, as the language usually remains Hebrew even if
you focus the URL bar with the mouse.



16 years ago
Summary: (possibility of changing) text input language in the URL bar upon getting keyboard focus → When URL bar gets focus, language should switch to English

Comment 20

16 years ago
*** Bug 223014 has been marked as a duplicate of this bug. ***

Comment 21

15 years ago
The fix for bug 162242 probably removes the problem that led to opening this
one. Since Mozilla doesn't autoswitch input languages any more, the problem, as
detailed in comment #14 no longer occurs (tested with current trunk builds of 1.7a).

It's important to decided whether any language autoswitching is planned for the
future, if not, then this bug should be marked as WONTFIX.


Comment 22

15 years ago
Let's see what the people from bug 162242 have to say about this. This still,
after all, a request for enhancement, not a bug.

Comment 23

15 years ago
Eyal, that's what WONTFIX resolutions are for - closing requests for
enhancements that we don't deem as beneficial.


Comment 24

15 years ago
If the URL bar switches to english when clicking in it:
Will I still be able to go to http://www.øl.no or http://www.blåbær.no/ - and
will it look like the norwegian special characters, or like something else?

Comment 25

15 years ago
To put it a little clearer... Wouldn't this RFE conflict with the work done for
ACE encoded host names in bug 196717, as well as collide with standards from the
IETF idn working group? (http://www.i-d-n.net/)

Comment 26

15 years ago
The TLD is going to remain in English, so one could write this part first, then
press Home and switch language to write the rest of the domain. Another option
could be to switch language to the one defined by the OS locale.

Ok, now that I'm done playing the devil's advocate, let me stress again that I'm
all for closing this bug as wontfix. Language auto-switching may be cool in
theory, but it blows when it comes to UI consistency and predictability.

Other than UI consistenty, Firefox's urlbar uses "Google's I'm feeling lucky"
when non-uri is entered. Doing this means we're going to annoy Hebrew users of
this feature.
Just verified, it's also possible to use non enUS keywords for bookmarks.

Comment 29

14 years ago
I still believe that statistically, 95% of the times someone is entering text in
the URL bar in a different language than English (or a language in which one can
enter the latin alphabet; if your keyboard layout is French switching doesn't
really matter) - it is because they have not noticed that their keyboard layout
had changed, have clicked the URL bar and are expecting to see http://something
or www.something instead of '''ץדםצקאיןמע or יאאפ:..  (which is what you get
with Hebrew keyboard layout). I agree that there may be some cases in which you
start your URL with non-latin text (e.g. a keyword for a bookmark, or a domain
name which does not only contain but also begin with non-latin characters), but
these are relatively few and far between.

Comment 30

13 years ago
I use Hebrew in the URLbar very often.
Many of my bookmarks shortcut is Hebrew chars.
For example, instead of typing www.mozilla.org I type "מ"...

In addition, I type hebrew words in the URLbar using "I'm feeling lucky" feature.
For example, instead of typing http://www.mozilla.org.il/ I type "מוזילה" and google redirects me to www.mozilla.org.il.

Comment 31

13 years ago
(In reply to comment #30)
> I use Hebrew in the URLbar very often.

You seem to be the exception rather than the rule. Still, this should certainly not be forced onto you - there should be a pref.

Comment 32

13 years ago
I've begun work on an extension for this, but I can't seem to pinpoint which event I should be adding a listener for, and for which object exactly.

Comment 33

13 years ago
Created attachment 218724 [details]
disfunctional extension

Comments and suggestions regarding the extension, or rather how to make it actually do something useful, are welcome.
Assignee: smontagu → nobody
Component: Layout: BiDi Hebrew & Arabic → Location Bar and Autocomplete
Product: Core → Firefox
QA Contact: bugs.mano → location.bar
Whiteboard: WONTFIX?

Comment 34

13 years ago
Uh, no, that's not welcome. I see no reason why this shouldn't be possible by pref.
Whiteboard: WONTFIX?

Comment 35

13 years ago
This is really must-implement feature for non-english speaking users (like me). It is very annoying to switch language from russian to english before typing url.
New customize option is appreciated. When turned on, it should automatically switch keyboard layout to English language when cursor is set to address bar and do nothing more. This will prevent problems with URI-s and copy-pasting.

Comment 36

11 years ago
Non-latin URLs have been possible for some time. For example, you can get URLs in Japanese or Chinese. Automatic switching would make these hard to type.

I don't know about other languages, but on a Japanese keyboard there is a key to switch to entering latin characters. One keypress isn't much...
IMO the awesome bar has made this definitely WONTFIX. I start typing in Hebrew at least as often as in English in the URL bar these days.

Comment 38

11 years ago
In this case, I'd like this as a preffed feature.
Not going to add a pref for this, can be done as an extension I'm sure.
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.