641238 - The location bar alignment should be LTR, even though the Firefox build is RTL (e.g. Hebrew, Arabic..) — Regression from Firefox 3.6

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, enhancement)

Description

[RealName]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b10) Gecko/20100101 Firefox/4.0b10
Build Identifier: Firefox/4.0rc

(This applies only to RTL builds of Firefox).

Dear Mozilla,
Since ff4 beta 11, all of the urls under the location bar (those that you can see either with the history feature or the switch-to-tab feature) are set in an RTL position, which is rather disturbing.

I assume that this is probably done to mimic Chrome & IE9, but you haven't considered the option that they're both doing it all wrong.
The RTL positioning just makes absolutely no sense, I would suggest you to construct a poll before such a decision, but now it's too late I guess.
If you'll check on the community you'd see that this step has practically zero supporters.

(I'm not saying that this should be completely reverted back to the way it was in b10, but at least give the users an option to choose whichever way they think is best for them)

I would understand it if the web addresses were written in Persian, but as of now 99% of the URLs are written in Latin characters, so fixing them to an RTL position seems like a completely unnatural thing to do.

Hopefully this importunity will be considered, so on behalf of a  countless number of RTL Firefox users, thanks in advance.

Reproducible: Always

Comment 1

[Tomer Cohen :tomer]

Unlike Google Chrome and maybe some other recent browsers, Firefox does include 'http://' prefix for all web addresses, which make it look weird even when the URL is fully localized, such as the case of http://דוגמה.טעסט and http://مثال.إختبار. It also make heavier risk for domain spoofing as the URI direction isn't consistent between two Firefox locales (see also bug 525831).

Comment 2

[Dima]

I'm also see no reason to keep it on the right side.
on the left side it's more comfortable.

I have no idea where is the logic behind this step.

Comment 3

[Itiel]

I agree!
It's not comfortable, unlike firefox 3.6.15.
Pay attention that in the previous version of firefox, no one complained about that = there is no need to change any of this.

At least you could give the chance to change it from about:config but I see no option for that.
Tell me if i'm wrong.

Dear Mozilla- please change it in the next version (4.0.1 or something).
Thanks.

Comment 5

[Tomer Cohen :tomer]

We are weeks from the next release, and this issue is one of the top local feedbacks we got about the Firefox 4.0 release.

Comment 6

[Axel Hecht [:Pike]]

Bug 610682 is hard to read, but it seems that arguments have been made there for either right and left aligned for the url. Limi?

Whatever the resolution of this bug is, it's not going to make it into Firefox 5. That's how the new release schedule goes.

Comment 7

[Anas Husseini [:linostar]]

Just to make one point clear. The location bar in RTL Firefox is in *LTR* direction, however it is right-aligned (which is very different than stating that the location bar is RTL). You can verify this if you add a trailing slash to any url in the location bar. That being said, the current behavior of the location bar doesn't break any RTL logic. It is rather a designing argument: whether to make the alignment to the right to imitate the LTR browser behavior (start of location bar close to 'back' and 'forward' buttons), or to revert it to the left alignment to preserve previous versions' behavior.

I am not with nor against reverting the alignment. I believe it is a design change that some users aren't still accepting (like many of the changes introduced in Fx4).

Comment 8

[matanya]

I'm affected by this bug too. It is really confusing to read the addressbar this way. please left-align it.

Comment 9

[Aakash Desai [:aakashd]]

Limi, Faaborg: Can you guys offer your opinion about this bug (per Axel's request in Comment #6)?

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

>Bug 610682 is hard to read

yep, just tried to read it, it was hard.  Just so everyone is on the same page, is this basically what we are currently shipping?

https://bug610682.bugzilla.mozilla.org/attachment.cgi?id=505874

The problem with that layout is that the URLs themselves are still of course LTR, so it is hard to parse the most important part of the URL scanning down, since the URLs are of varying length, and your eyes have to do a lot of additional horizontal movement.

I would be in favor of keeping the chrome controls in the same locations (go button on the left), but moving the identity block and URL to the same location as LTR builds.  Is that the same thing that users are also commonly requesting, and the same behavior of 3.6?

Comment 11

[dror3go]

(In reply to comment #10)
> I would be in favor of keeping the chrome controls in the same locations (go
> button on the left), but moving the identity block and URL to the same
> location as LTR builds.  Is that the same thing that users are also commonly
> requesting, and the same behavior of 3.6?

This is how it looked in 3.6, and what most users requesting:
http://mozilla.org.il/firefox/firefox36-toolbar4.png

Comment 12

[RealName]

@dror3go, exactly.
Although it would be great if you've also had a picture of the FF3.6 dropdown menu (which was left aligned).
IMHO, the dropdown menu is much more important to be LTR, that's 6 URLs you need to be able to properly look at.
(Nevertheless, both the dropdown menu and the adress bar got to be LTR, obviously.)

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

>This is how it looked in 3.6, and what most users requesting:
>http://mozilla.org.il/firefox/firefox36-toolbar4.png

yeah, makes sense since it makes the URLs easier to scan in a list.  I'm in favor of us going back to that alignment as well.

Comment 14

[Amiad]

In the forums of Mozilla Israel , the users everytimes complain on this bug.
http://mozilla.org.il/board/viewtopic.php?f=9&t=10434 (Hebrew).

Comment 15

[[:Cww]]

Tracking isn't what you want. Assigning bug to try to get some more action, clearing tracking nom.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

cc'ing some of our front end developers.  This change is highly wanted by a sizable chunk of the world's population.

Comment 17

[Tomer Cohen :tomer]

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #16)
> This change is highly wanted by a sizable chunk of the world's population.

Thanks. I am sure this will make our friends happy now. ☺

Comment 18

[Itiel]

(In reply to Tomer Cohen :tomer from comment #17)
> (In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #16)
> > This change is highly wanted by a sizable chunk of the world's population.
> 
> Thanks. I am sure this will make our friends happy now. ☺

I highly recommend that there will be a new option in about:config, which will offer to change the the location bar alignment- LTR or RTL.
That way, ANYONE will be satisfied, right? :)

Comment 19

[RealName]

@itiel_yn8 +1 to that =]

Comment 20

[Tomer Cohen :tomer]

I'd prefer to use dir=auto, so the location bar would be LTR for normal addresses but for RTL addresses such as http://דוגמה.טעסט would be in RTL (thous aligned to right).

Comment 21

[Itiel]

(In reply to Tomer Cohen :tomer from comment #20)
> I'd prefer to use dir=auto, so the location bar would be LTR for normal
> addresses but for RTL addresses such as http://דוגמה.טעסט would be in RTL
> (thous aligned to right).

But it will look a bit weird.
I think Mozilla will apply this (if so) for EVERY address. The users want the alignment to be at one side, they want something organized and not to switch sides every time ><

Besides, in both RTL & LTR, the hebrew words are looking good.

P.S. It's good to see you here tomer :P

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

The introduction of an about:config pref is fine, but by default we need to make sure that URLs are easy to read and scan, and are consistently LTR for all locals.

Comment 23

[Jared Wein [:jaws] (please needinfo? me)]

So just to get this correct, would we like the urlbar to look like this?

RTL: [⟳∇⛾ www.yahoo.com ★]
LTR: [⛾ www.yahoo.com ★∇⟳]

I think we should move the ★ to the right side in RTL because the showing/hiding of it will cause the website address to jump around.

NB: For those without a good Unicode font, ⛾ is "unicode cup on black square" (favicon).

Comment 24

[Frank Yan (:fryn)]

Since Cww arbitrarily assigned it to Simon without his input, and since Jared and I have actually been looking at it, I'm changing the assignee to Jared.

Comment 25

[Jared Wein [:jaws] (please needinfo? me)]

A better illustration showing text-alignment:

RTL: [⟳∇⛾ www.coffee.example                   ★]
LTR: [⛾ www.coffee.example                   ★∇⟳]

Is this what we want?

Comment 26

[RealName]

Hey, I think I'll just download FF 3.6 (where the url bar was still in perfect shape) and post you guys a screenshot, before one of you will turn into an ASCII artist.

Comment 27

[RealName]

Attachment: *Desired situation*

Comment 28

[Itiel]

@ RealName
WOW it takes me back.. :)

Anyway, I think it should be like that-
RTL: [∇⛾ www.coffee.example                   ★⟳]
I don't care if it will be like that-
     [∇ www.coffee.example                   ★⟳⛾]

LTR: [⛾ www.coffee.example                   ★∇⟳]

Comment 29

[Alex Faaborg [:faaborg] (Firefox UX)]

>RTL: [⟳∇⛾ www.coffee.example                   ★]
>LTR: [⛾ www.coffee.example                   ★∇⟳]

>Is this what we want?

yep. This way the star and favicon line up with where they appear in the auto complete results.  Also in RTL the drop down arrow and reload are placed on the "not as important side," just as they are in LTR.

Comment 30

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Screenshot of current work-in-progress

I have tried to follow the ASCII artwork in this bug as follows :)

Comment 31

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Screenshot of current work-in-progress with awesome bar

Comment 32

[Itiel]

(In reply to Jared Wein [:jwein] from comment #31)
> Created attachment 557388 [details]
> Screenshot of current work-in-progress with awesome bar

Actually... looking good!
But I'll customize it anyway :P

P.S. the green button and the refresh button aren't in the same size (I guess).

Comment 33

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to ETL from comment #32)
> 
> P.S. the green button and the refresh button aren't in the same size (I
> guess).

You've got good eyes :)

The two screenshots are an hours worth of work apart. The screenshot with the Awesome Bar showing is the more recent one.

Comment 34

[RealName]

@jwein, I have to say that the design pretty much looks perfect in terms of the RTL issue. Are you a Hebrew speaker/reader?

Regarding the icons, I think that to each his own, and anyway the whole deal is fairly customizable. E.g. This is how I find my arrangement sexy:
http://s3.postimage.org/4o22a9es8/image.png
(Perhaps it will change once the RTL issue is fixed, but I guess that's one of the reasons that make Firefox so great).

Comment 35

[RealName]

*I meant it as a rhetorical question it just came out weird, don't answer it XD

Comment 36

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Screenshot of current work-in-progress with notification popup

This is a screenshot of the browser with a notification popup. Note how when the URL bar loses focus, the notification arrow is slightly the wrong color (#fff vs rgba(255,255,255,.725)).

This problem exists in currently released versions of Firefox but is not as noticeable since the colors are not next to each other.

Please let me know if this needs to be fixed before landing.

Comment 37

[Itiel]

NO NO NO!
The notifications popup should be in right, it is obvious to all hebrew&arabic etc speakers and writers.
Now that I see it, I realize the favicon should be at right and DEFINITELY NOT in side left.
And everyone else can agree with that (plz don't upset me ><).

Comment 38

[RealName]

@ETL are you serious? The man is just purely trying to help, and no, he's not an Hebrew/Arabic speaker (& Even if he were, I am still astounded by your comment).

Comment 39

[(no longer active)]

While I don't like the tone of comment 37, I think that the content is correct.  Showing doorhanger notifications on the left side is inconsistent with our RTL UI design.

Comment 40

[matanya]

I agree with comment 39. this should remain on the right side.

Comment 41

[Itiel]

No.. :)
Guys, I was talking only with pure intentions, I'm sorry if you misunderstood me.
I was just trying to explain myself in the best way I could.

@ Jared Wein & RealName
I did not mean any harm.. sorry once again. :)

Comment 42

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to ETL from comment #37)
(In reply to RealName from comment #38)
(In reply to Ehsan Akhgari [:ehsan] from comment #39)
(In reply to matanya from comment #40)
(In reply to ETL from comment #41)

No harm done, but there's also no need to shout ;)

The reasoning behind the favicon being on the left side is for consistency with the results in the Awesome Bar popup.

I placed the doorhanger and notifications next to the favicon because they are visually connected in our current implementations.

Would people rather want this style for RTL (where the notification appears on the far right side?):
RTL: [⟳∇⛾ www.coffee.example                   ★<]

Comment 43

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Jared Wein [:jwein] from comment #42)
> Would people rather want this style for RTL (where the notification appears
> on the far right side?):
> RTL: [⟳∇⛾ www.coffee.example                   ★<]

Nevermind, fryn pointed out to me that it is important that the notification icon points at the favicon (which is used for site identity information).

Comment 44

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug 641238

Comment 45

[(no longer active)]

I tested the patch on Mac, and it's really good.  The only problem that I noticed was the lack of left-padding on the textbox in the URL bar.

Comment 46

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 557914 [details] [diff] [review]
Patch for bug 641238

Removing review requests since it is not working good enough on Mac.

Comment 47

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug 641238

Comment 48

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug 641238

I noticed that the previous patch was a couple pixels off on gnomestripe.

Comment 49

[Jared Wein [:jaws] (please needinfo? me)]

Here is a link to the try build: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=2789e22c1539

Comment 50

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 557689 [details]
Screenshot of current work-in-progress with notification popup

generally fine, small nit with getting the arrow to line up to the center of the anchor.

Comment 51

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 557388 [details]
Screenshot of current work-in-progress with awesome bar

generally fine, small nit that it would be nice if possible to have the results vertically line up with the favicon and entered text (instead of starting at the end of the field with the go button)

Comment 52

[Alex Faaborg [:faaborg] (Firefox UX)]

>This problem exists in currently released versions of Firefox but is not as >noticeable since the colors are not next to each other.

you're talking about the line between the arrow and the window frame?  If so I don't see how that problem wouldn't be exactly the same as the LTR builds.

Comment 53

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Screenshot of regression with notification arrow

I have added a screenshot that specifically points out the regression of the notification arrow.

Offline faaborg mentioned that we may be able to place a border on the right side of the arrow so it looks more natural.

Comment 54

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 558723 [details]
Screenshot of regression with notification arrow

yeah a border would be fine

Comment 55

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 558020 [details] [diff] [review]
Patch for bug 641238

Switching review? to feedback? due to the nits/issues that faaborg brought up.

Comment 56

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 558020 [details] [diff] [review]
Patch for bug 641238

David: This patch changes the order of the location bar elements using -moz-box-ordinal-group. Can you please provide feedback so as to make sure that I am not breaking any assumptions of accessibility users?

Comment 57

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 558020 [details] [diff] [review]
Patch for bug 641238

f=me since I don't think this will regress accessibility. We need to confirm with Marco so I've requested his feedback. Jared thanks for checking with me/us.

Comment 58

[Marco Zehe (:MarcoZ)]

Comment on attachment 558020 [details] [diff] [review]
Patch for bug 641238

I do not believe this makes any difference for blind users. Arabic and Hebrew in braille are left to right always, even when visually stuff is written right to left. Screen readers do an automatic conversion based on the characters used. So I think this is fine. I never heard any complaints, so Arabic or Hebrew blind users probably never noticed this change in the first place. f=me.

Comment 59

[(no longer active)]

Jared: do you have an estimate whether this makes it into Firefox 9 or not?  I'd really love for it too.  Let me know if I can help.  Thanks!  :-)

Comment 60

[RealName]

Or FF8, or FF7. Nah I'm only kiddin', anytime would be awesome :)

Comment 61

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Ehsan Akhgari [:ehsan] from comment #59)
(In reply to RealName from comment #60)

I can upload an updated patch today (Friday) in the hopes that it can be reviewed quickly and if there are any changes required that I can implement them in time.

I think the biggest thing holding it back is adjusting the width of the awesome bar dropdown. If we can live with the results not matching horizontally with the url bar items then landing this may be possible for Fx9.

I'll post an update here if anything changes.

Comment 62

[(no longer active)]

(In reply to Jared Wein [:jwein] from comment #61)
> I think the biggest thing holding it back is adjusting the width of the
> awesome bar dropdown. If we can live with the results not matching
> horizontally with the url bar items then landing this may be possible for
> Fx9.

That's a polish, right?  I guess we can do that in a followup bug...  :-)

Comment 63

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug 641238

Fixed the minor nits that were mentioned before.

This patch still has the issue that the urlbar drop down favicons don't line up with the current site favicon, but fixing that is non-trivial due to how we determine widths of popup windows.

Comment 64

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 562187 [details] [diff] [review]
Patch for bug 641238

normally would want to review a screenshot, but since this jsut fixes the earlier mentioned nits, ui-r+

Comment 65

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug 641238

Unbitrotted. Carrying forward ui-review from faaborg.

Comment 66

[Jared Wein [:jaws] (please needinfo? me)]

Review ping

Comment 67

[(no longer active)]

Dao: ping?

Comment 68

[Dão Gottwald [:dao]]

You don't need to ping me, it won't make my review queue shorter.

Comment 69

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug 641238

Unbitrotted. Carrying forward ui-r+ from faaborg.

Comment 70

[Dão Gottwald [:dao]]

Comment on attachment 567452 [details] [diff] [review]
Patch for bug 641238

I'm still going to review this.

Comment 71

[(no longer active)]

Comment on attachment 567452 [details] [diff] [review]
Patch for bug 641238

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

This looks good to me, but I'll let Dao review since he knows this code a lot better than me.

Comment 72

[RealName]

Just out of curiosity, will it still make it to Fx9?

Comment 73

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to RealName from comment #72)
> Just out of curiosity, will it still make it to Fx9?

I'm sorry but it won't make Fx9 or Fx10. I think the holdup on this bug was that we also wanted to land the conditional forward button (bug 674744 and bug 682534), which bitrots the associated patch heavily.

The conditional forward button has now been landed, and so I can resume work on this bug to unbitrot it and try to get it in for Fx11.

Comment 74

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jwein and :jaws] from comment #73)
> (In reply to RealName from comment #72)
> > Just out of curiosity, will it still make it to Fx9?
> 
> I'm sorry but it won't make Fx9 or Fx10. I think the holdup on this bug was
> that we also wanted to land the conditional forward button (bug 674744 and
> bug 682534), which bitrots the associated patch heavily.

Partly, yes. The other reason is that I didn't find time to do the review. My review queue is at least slightly relaxed now...

Comment 75

[RealName]

Ok, thanks :)

Comment 76

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: WIP of patch for bug 641238

This unbitrots the previous patch. I still have to add support for gnomestripe, as well as fix one of the selectors to not use a descendent selector.

Comment 77

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug 641238 v2

I have tested this on gnomestripe and removed the descendent selector that was present in the previous WIP patch.

Comment 78

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 579426 [details] [diff] [review]
Patch for bug 641238 v2

This patch is mostly done, but the notification-popup-box had to be made wider to get the doorhangers to position themselves in the correct place.

There is also some pixel-tweaking that should be done for gnomestripe.

Dao, do you have any tips for the notification-popup-box adjustments?

Comment 79

[RealName]

Happy new year everyone!

Are there any news about the bug?

Comment 80

[RealName]

*Is

Comment 81

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to RealName from comment #79)
> Are there any news about the bug?

I'm waiting on feedback from Dao.

Comment 82

[Dão Gottwald [:dao]]

Comment on attachment 579426 [details] [diff] [review]
Patch for bug 641238 v2

(In reply to Jared Wein [:jwein and :jaws] from comment #78)
> Comment on attachment 579426 [details] [diff] [review]
> Patch for bug 641238 v2
> 
> This patch is mostly done, but the notification-popup-box had to be made
> wider to get the doorhangers to position themselves in the correct place.
> 
> There is also some pixel-tweaking that should be done for gnomestripe.
> 
> Dao, do you have any tips for the notification-popup-box adjustments?

I'm not sure what exactly you're asking, so I don't have any tips offhand...

Comment 83

[Jared Wein [:jaws] (please needinfo? me)]

This is what I was asking about:

(In reply to Jared Wein [:jwein and :jaws] from comment #78)
> This patch is mostly done, but the notification-popup-box had to be made
> wider to get the doorhangers to position themselves in the correct place.
> 
> Dao, do you have any tips for the notification-popup-box adjustments?

Comment 84

[Jared Wein [:jaws] (please needinfo? me)]

Making the notification-popup-box wider means there is extra distance between the notification icon and the URL. I've tried a negative margin on the URL, but that breaks the hostname coloring, causing the URL to be drawn in all-black (no grey).

Comment 85

[Dão Gottwald [:dao]]

You're stating it as a fact that the box had to be made wider. Why? This isn't obvious to me...

I'm surprised that there's no progress because you're waiting for feedback. If this bug is stalled, add the helpwanted keyword, and if it's really badly stalled and you see no way out, assign it to [e-mail] so that somebody else can try to pick it up. Of course, if you have multiple approaches to a problem in mind, I can try to tell which one sounds more promising to me. I can also try to answer specific technical questions. But in general, I understand feedback as something you want to get in parallel while you're working on something. It's not a magic problem solver flag.

Comment 86

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Dão Gottwald [:dao] from comment #85)
> You're stating it as a fact that the box had to be made wider. Why? This
> isn't obvious to me...

Making it wider was the only way I could figure out how to keep the doorhanger arrow centered on the icon.

This bug isn't necessarily stalled, I just haven't been spending much time on it recently. I plan on getting to it this week and will upload an updated patch soon.

Comment 87

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jwein and :jaws] from comment #86)
> (In reply to Dão Gottwald [:dao] from comment #85)
> > You're stating it as a fact that the box had to be made wider. Why? This
> > isn't obvious to me...
> 
> Making it wider was the only way I could figure out how to keep the
> doorhanger arrow centered on the icon.

This sounds like a bug. Have you considered filing it? A reduced testcase would probably help.

Comment 88

[Jared Wein [:jaws] (please needinfo? me)]

Current status on this bug is that I'd like to wait for bug 588270 to land as it will cause bitrot on this patch. I also need to talk to UX about how we want the notification-popup-box to look when there isn't a favicon next to it.

Comment 89

[RealName]

Any news on the bug?

Comment 90

[Jared Wein [:jaws] (please needinfo? me)]

No new patch, but the work that this was waiting on (bug 588270, then bug 742419) is now complete. I plan on getting to this bug within the next two weeks.

Comment 91

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug v3 (browser/base, winstripe, gnomestripe)

This patch left-aligns URLs in the location bar and rearranges the elements within the location bar as described in comment #29.

Some elements might not need -moz-box-ordinal applied to them but I applied the property a little more generously to make it easier for others to understand the order.

I'll upload a separate patch for pinstripe after this gets r+.

Comment 92

[Jared Wein [:jaws] (please needinfo? me)]

Dao: review ping?

Comment 93

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 619554 [details] [diff] [review]
Patch for bug v3 (browser/base, winstripe, gnomestripe)

Blair, do you think you can take a look at this patch? It is obviously bitrotted by now, but I want to see what someone else thinks about this approach.

Comment 94

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 619554 [details] [diff] [review]
Patch for bug v3 (browser/base, winstripe, gnomestripe)

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

Yep, I like the approach.

Just eyeballed the code though, so just f+ - r? after you unbitrot :) Really needs some live testing.

::: browser/base/content/browser.css
@@ +212,1 @@
>  html|input.uri-element-right-align:-moz-locale-dir(rtl),

Any reason to keep uri-element-right-align? Doesn't seem to be used anywhere else.

Comment 95

[RealName]

Fx16 was just released, any news regarding the bug?

Comment 96

[Jared Wein [:jaws] (please needinfo? me)]

Yeah, I'll pick up work on this bug again within the next week. Thanks for the feedback Blair.

Comment 97

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch v3 (updated, unbitrotted) (only tested on Windows)

This patch is unbitrotted and works great on Windows.

I found an issue in the previous patch with the ctrl+shift+x shortcut to shift the text direction that was shifting the text to the left by ~8 pixels. With help from smontagu, I added the unicode-bidi: -moz-plaintext CSS property to disable the ctrl+shift+x functionality on this field.

Comment 98

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 669867 [details] [diff] [review]
Patch v3 (updated, unbitrotted) (only tested on Windows)

Clearing this after IRC discussion of going ahead with OSX/Linux, based on previous patch.

Comment 99

[RealName]

Any news on the bug?

Comment 100

[Jared Wein [:jaws] (please needinfo? me)]

Unassigning as I haven't been working on this and I don't want to hold people up.

Comment 101

[Itiel]

To be honest- I don't think it matters anymore.
Since this changed, I think every hebrew Firefox user got used to it.

Don't you agree, RealName?

Comment 102

[Itiel]

BUT it would be useful if the user could change it manually (via a setting, about:config setting or even just a Ctrl + Left Shift, which does not work).

Comment 103

[Anas Husseini [:linostar]]

@ETL
You can toggle the location bar alignment by pressing ctrl+shift+x.

Comment 104

[Itiel]

(In reply to Anas Husseini [:linostar] from comment #103)
> @ETL
> You can toggle the location bar alignment by pressing ctrl+shift+x.

Oh, cool. Thanks :)
Is it permanent? I mean if I reboot Firefox will it be saved? (Don't wanna close my 150 tabs to test)
And if so, see again comment 101.

Comment 105

[Anas Husseini [:linostar]]

Yes, it is permanent. In fact, it has been there for quite a while.

Comment 106

[Tomer Cohen :tomer]

(In reply to Anas Husseini [:linostar] from comment #105)
> Yes, it is permanent. In fact, it has been there for quite a while.

AFAIK this is not permanent between browser restarts or even different browser windows. I just got used to click this key combination every time I starts the browser.

Comment 107

[Anas Husseini [:linostar]]

Sorry, I thought his question is about the existence of this key combination, not about its duration and scope.

Comment 108

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.