Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Findings and tiny consistency inacuracies found while making #49 (and a bit #17 too ngl) #51

Open
Kiki79250CoC opened this issue Feb 29, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@Kiki79250CoC
Copy link
Contributor

Kiki79250CoC commented Feb 29, 2024

So, I found several bugs and one inconsistency that can help to improve accurateness of Echelon.
OK it may look loooooong, but the fixes are mostly not that long to implement, it's just me that over-documents my reports.

I. Misses

1. Australis Panel - "Help" submenu title is not localized

It seems that the "Help" menu title is written as it in the code instead of taking their localized value.

7

II. Bugs

1. Australis - "Customize" button's tooltip

This one is somewhat not noticeable on first look, because it concerns the tooltip for the "Personalize" button.
More precisely, the tooltip that button should receive upon browser startup is not applied, resulting of an unwanted behavior.

I'll explain with images, it would be more simple :

# Image Text
1 1 On the first image, you can notice that I'm pointing the button with my cursor, but nothing happens.

My supposition is that the tooltip value is empty, which cause to not display it.
2 2 On the second image, I went into the edition mode, and when I hover the button, the "close" tooltip is displayed
3 3 On the third image, I exited the edition mode, and when I hover the "Personalize" button again, the tooltip remains to the "Close" one.

My supposition is that when the edition mode closes, the same code that fails to apply the tooltip on image 1 is executed, but as the value is empty, that value is considered as a "change nothing" signal and keep the previous tooltip.

2. Australis - Settings pane can be weirdly sized due to FxDE or FxN "help" link at the bottom

The title speaks for itself. I'm sure it'll not happen on a normal Firefox installation

Image (collapsed)

8

3. Strata - Firefox button is no longer colorized after it's default branch

I don't think it's an intentional change, as I found that attention to details very good!
In fact that bug appeared on v1.1, which is why I used v1.0 on the image.

6

4. Strata/Australis - On Private Browsing, the icon is not always applied when a new tab is created

When you open the Private browsing, everything is fine, the icon is there, but I noticed that when you create a new tab, the icon used is not the one provided by Echelon but the default one.

I also noticed that if you refresh the tab, the Echelon-provided icon is used as expected.

Icon

5. Strata/Australis - This.

On Firefox 106 up to Firefox 118, you can disable the "new" private browsing indicator (with text) using browser.privatebrowser.enable-new-indicator to the old one which only have the icon.

This was something I enabled upon Firefox 106 release because their separation of private/not private is somewhat awful (to me) and I forgot about that since.

It seems this hidden key (because referenced nowhere) escaped you and the displayed icon is, as you can expect, the default one.

18 19

20

(Also as you can see the 'unsupported version' warning is displayed as this is FxDE 115.0b9, and obviously I cannot easily to further because Windows 7).

III. Suggestions for better accurateness

1. Strata - Add a bit of spacing to better match Firefox 4 menu on localized languages with long strings

Actually I found this thing while doing #17, but waited to having a more appropriate moment to report it (like now).
As you can see, when using the French locale, you can notice that the "new private window" and "add-ons" menu items are really close to the edge of their respective side. I highlighted in red the gap between the end of the text and the edge of the menu's area

11

I checked on Firefox 4.0.1 and the menus have a kind of padding which is the size of the arrow for menus items that have one for making sure those kind of long strings have space to be displayed without reach the far right side of the menu.

13

I make some images which can illustrate the spacing through the menu items, with a red line

Firefox 4.0.1 Echelon
5 12
14 15
Full menu comparison (collapsed)
Firefox 4.0.1 Echelon
16 17

If I take the Mozilla team logic, they added an additional space (of the size of the "arrow" block) to the right of items that don't have an arrow to make sure arrows are the only entities to be placed on the far right border of each column, so I think it can be possible to replicate that particularity in order to get something more accurate to the original Firefox 4 menu.

2. Add tiny space to right side of tab bar to avoid "+" button if tab manager is disabled

Something optional, but can be done for better accuracy.

Firefox 4.0.1 Echelon
9 10

That's all!

Yeah I agree that I probably worked too much to do that report, but I think good reports should be as complete than this one, it's more comprehensive for the maintainers themselves and everyone else that is reading this report.

@Erizur Erizur added the enhancement New feature or request label Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants