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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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? Prog.
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.
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. Prog.
Adding firstname.lastname@example.org (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"). Prog. PS. that should have been "messes with my input language" rather than "messes around with my input language" ;-)
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
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.
Is this something we want to fix for all platforms or only for Windows?
> 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. Prog.
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 http://imagic.weizmann.ac.il/~dov/Hebrew/logicUI24.htm#h1-9
Assignee: mkaply → smontagu
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 162242.
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. -or- 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? Prog.
Ah, but the whole point of filing this bug is avoiding the need for extra keypresses to ensure LTR direction in the URL bar...
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 -> LeftAlt+Shift. As I said, this is ugly compared to the simple (yet effective) way that other browsers handle language switching. Prog.
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. Prog.
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
*** Bug 223014 has been marked as a duplicate of this bug. ***
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. Prog.
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.
Eyal, that's what WONTFIX resolutions are for - closing requests for enhancements that we don't deem as beneficial. Prog.
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?
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/)
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. Prog.
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.
QA Contact: zach → bugs.mano
Just verified, it's also possible to use non enUS keywords for bookmarks.
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.
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.
(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.
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.
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
Uh, no, that's not welcome. I see no reason why this shouldn't be possible by pref.
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.
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.
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.