Closed
Bug 641238
Opened 14 years ago
Closed 7 years ago
The location bar alignment should be LTR, even though the Firefox build is RTL (e.g. Hebrew, Arabic..) — Regression from Firefox 3.6
Categories
(Firefox :: Address Bar, enhancement)
Firefox
Address Bar
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: sprint69, Unassigned)
References
Details
(Keywords: rtl)
Attachments
(2 files, 13 obsolete files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
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).
Severity: normal → enhancement
Summary: The aligning below the url bar should be LTR, even though the Firefox build is RTL (e.g. Hebrew, Arabic..) → The location bar alignment should be LTR, even though the Firefox build is RTL (e.g. Hebrew, Arabic..) — Regression from Firefox 3.6
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.
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•14 years ago
|
||
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•14 years ago
|
||
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.
Depends on: 610682
Comment 7•14 years ago
|
||
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).
I'm affected by this bug too. It is really confusing to read the addressbar this way. please left-align it.
Comment 9•13 years ago
|
||
Limi, Faaborg: Can you guys offer your opinion about this bug (per Axel's request in Comment #6)?
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•13 years ago
|
tracking-firefox8:
--- → ?
Comment 10•13 years ago
|
||
>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•13 years ago
|
||
(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
Reporter | ||
Comment 12•13 years ago
|
||
@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•13 years ago
|
||
>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•13 years ago
|
||
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•13 years ago
|
||
Tracking isn't what you want. Assigning bug to try to get some more action, clearing tracking nom.
Assignee: nobody → smontagu
tracking-firefox8:
? → ---
Comment 16•13 years ago
|
||
cc'ing some of our front end developers. This change is highly wanted by a sizable chunk of the world's population.
Comment 17•13 years ago
|
||
(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•13 years ago
|
||
(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? :)
Reporter | ||
Comment 19•13 years ago
|
||
@itiel_yn8 +1 to that =]
Comment 20•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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.
Assignee: smontagu → jwein
Status: NEW → ASSIGNED
Comment 25•13 years ago
|
||
A better illustration showing text-alignment:
RTL: [⟳∇⛾ www.coffee.example ★]
LTR: [⛾ www.coffee.example ★∇⟳]
Is this what we want?
Reporter | ||
Comment 26•13 years ago
|
||
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.
Reporter | ||
Comment 27•13 years ago
|
||
Comment 28•13 years ago
|
||
@ 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•13 years ago
|
||
>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•13 years ago
|
||
I have tried to follow the ASCII artwork in this bug as follows :)
Attachment #557382 -
Flags: feedback?(faaborg)
Comment 31•13 years ago
|
||
Attachment #557388 -
Flags: feedback?(faaborg)
Updated•13 years ago
|
Attachment #557382 -
Flags: feedback?(faaborg) → feedback+
Comment 32•13 years ago
|
||
(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•13 years ago
|
||
(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.
Reporter | ||
Comment 34•13 years ago
|
||
@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).
Reporter | ||
Comment 35•13 years ago
|
||
*I meant it as a rhetorical question it just came out weird, don't answer it XD
Comment 36•13 years ago
|
||
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.
Attachment #557689 -
Flags: feedback?(faaborg)
Comment 37•13 years ago
|
||
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 ><).
Reporter | ||
Comment 38•13 years ago
|
||
@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•13 years ago
|
||
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•13 years ago
|
||
I agree with comment 39. this should remain on the right side.
Comment 41•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
Attachment #557914 -
Flags: ui-review?(faaborg)
Attachment #557914 -
Flags: review?(dao)
Comment 45•13 years ago
|
||
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•13 years ago
|
||
Comment on attachment 557914 [details] [diff] [review]
Patch for bug 641238
Removing review requests since it is not working good enough on Mac.
Attachment #557914 -
Flags: ui-review?(faaborg)
Attachment #557914 -
Flags: review?(dao)
Attachment #557914 -
Flags: feedback?(dao)
Comment 47•13 years ago
|
||
Attachment #557914 -
Attachment is obsolete: true
Attachment #557914 -
Flags: feedback?(dao)
Attachment #557993 -
Flags: review?(dao)
Comment 48•13 years ago
|
||
I noticed that the previous patch was a couple pixels off on gnomestripe.
Attachment #557993 -
Attachment is obsolete: true
Attachment #557993 -
Flags: review?(dao)
Attachment #558020 -
Flags: review?(dao)
Comment 49•13 years ago
|
||
Here is a link to the try build: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=2789e22c1539
Comment 50•13 years ago
|
||
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.
Attachment #557689 -
Flags: feedback?(faaborg) → feedback+
Comment 51•13 years ago
|
||
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)
Attachment #557388 -
Flags: feedback?(faaborg) → feedback+
Comment 52•13 years ago
|
||
>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•13 years ago
|
||
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•13 years ago
|
||
Comment on attachment 558723 [details]
Screenshot of regression with notification arrow
yeah a border would be fine
Comment 55•13 years ago
|
||
Comment on attachment 558020 [details] [diff] [review]
Patch for bug 641238
Switching review? to feedback? due to the nits/issues that faaborg brought up.
Attachment #558020 -
Flags: review?(dao) → feedback?(dao)
Comment 56•13 years ago
|
||
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?
Attachment #558020 -
Flags: feedback?(bolterbugz)
Comment 57•13 years ago
|
||
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.
Attachment #558020 -
Flags: feedback?(marco.zehe)
Attachment #558020 -
Flags: feedback?(bolterbugz)
Attachment #558020 -
Flags: feedback+
Comment 58•13 years ago
|
||
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.
Attachment #558020 -
Flags: feedback?(dao) → feedback+
Comment 59•13 years ago
|
||
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! :-)
Reporter | ||
Comment 60•13 years ago
|
||
Or FF8, or FF7. Nah I'm only kiddin', anytime would be awesome :)
Comment 61•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
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.
Attachment #557382 -
Attachment is obsolete: true
Attachment #557388 -
Attachment is obsolete: true
Attachment #557689 -
Attachment is obsolete: true
Attachment #558020 -
Attachment is obsolete: true
Attachment #558723 -
Attachment is obsolete: true
Attachment #558020 -
Flags: feedback?(marco.zehe)
Attachment #562187 -
Flags: ui-review?(faaborg)
Attachment #562187 -
Flags: review?(dao)
Comment 64•13 years ago
|
||
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+
Attachment #562187 -
Flags: ui-review?(faaborg) → ui-review+
Comment 65•13 years ago
|
||
Unbitrotted. Carrying forward ui-review from faaborg.
Attachment #562187 -
Attachment is obsolete: true
Attachment #562187 -
Flags: review?(dao)
Attachment #563478 -
Flags: ui-review+
Attachment #563478 -
Flags: review?(dao)
Comment 66•13 years ago
|
||
Review ping
Comment 67•13 years ago
|
||
Dao: ping?
Comment 68•13 years ago
|
||
You don't need to ping me, it won't make my review queue shorter.
Comment 69•13 years ago
|
||
Unbitrotted. Carrying forward ui-r+ from faaborg.
Attachment #563478 -
Attachment is obsolete: true
Attachment #563478 -
Flags: review?(dao)
Attachment #567452 -
Flags: ui-review+
Attachment #567452 -
Flags: review?(ehsan)
Comment 70•13 years ago
|
||
Comment on attachment 567452 [details] [diff] [review]
Patch for bug 641238
I'm still going to review this.
Attachment #567452 -
Flags: review?(dao)
Comment 71•13 years ago
|
||
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.
Attachment #567452 -
Flags: review?(ehsan)
Reporter | ||
Comment 72•13 years ago
|
||
Just out of curiosity, will it still make it to Fx9?
Comment 73•13 years ago
|
||
(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•13 years ago
|
||
(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...
Reporter | ||
Comment 75•13 years ago
|
||
Ok, thanks :)
Comment 76•13 years ago
|
||
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.
Attachment #567452 -
Attachment is obsolete: true
Attachment #567452 -
Flags: review?(dao)
Attachment #575553 -
Flags: feedback?(dao)
Comment 77•13 years ago
|
||
I have tested this on gnomestripe and removed the descendent selector that was present in the previous WIP patch.
Attachment #575553 -
Attachment is obsolete: true
Attachment #575553 -
Flags: feedback?(dao)
Attachment #579426 -
Flags: review?(dao)
Comment 78•13 years ago
|
||
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?
Attachment #579426 -
Flags: review?(dao) → feedback?(dao)
Reporter | ||
Comment 79•13 years ago
|
||
Happy new year everyone!
Are there any news about the bug?
Reporter | ||
Comment 80•13 years ago
|
||
*Is
Comment 81•13 years ago
|
||
(In reply to RealName from comment #79)
> Are there any news about the bug?
I'm waiting on feedback from Dao.
Comment 82•13 years ago
|
||
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...
Attachment #579426 -
Flags: feedback?(dao)
Comment 83•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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 nobody@mozilla.org 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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
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.
Reporter | ||
Comment 89•13 years ago
|
||
Any news on the bug?
Comment 90•13 years ago
|
||
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•13 years ago
|
||
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+.
Attachment #579426 -
Attachment is obsolete: true
Attachment #619554 -
Flags: review?(dao)
Comment 92•13 years ago
|
||
Dao: review ping?
Comment 93•12 years ago
|
||
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.
Attachment #619554 -
Flags: review?(dao) → review?(bmcbride)
Comment 94•12 years ago
|
||
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.
Attachment #619554 -
Flags: review?(bmcbride) → feedback+
Reporter | ||
Comment 95•12 years ago
|
||
Fx16 was just released, any news regarding the bug?
Comment 96•12 years ago
|
||
Yeah, I'll pick up work on this bug again within the next week. Thanks for the feedback Blair.
Comment 97•12 years ago
|
||
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.
Attachment #619554 -
Attachment is obsolete: true
Attachment #669867 -
Flags: feedback?(bmcbride)
Comment 98•12 years ago
|
||
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.
Attachment #669867 -
Flags: feedback?(bmcbride)
Reporter | ||
Comment 99•12 years ago
|
||
Any news on the bug?
Comment 100•11 years ago
|
||
Unassigning as I haven't been working on this and I don't want to hold people up.
Assignee: jaws → nobody
Status: ASSIGNED → NEW
Comment 101•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
@ETL
You can toggle the location bar alignment by pressing ctrl+shift+x.
Comment 104•11 years ago
|
||
(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•11 years ago
|
||
Yes, it is permanent. In fact, it has been there for quite a while.
Comment 106•11 years ago
|
||
(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•11 years ago
|
||
Sorry, I thought his question is about the existence of this key combination, not about its duration and scope.
Updated•8 years ago
|
Comment 108•7 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•