Recommended Posts

5 hours ago, JUANMAS7ER said:

To be fair, almost all browsers look like a Chromium iteration these days. There's not a big feature that makes them apart from each other (at least visually) untill someone comes with any

When Firefox initially was released one of the criticisms was that it looked too much like IE6 (And that it "stole" tabs from Opera). All browsers feed off each other (They all do the same job) and it shouldn't be surprising, a good UI design idea is still a good idea, and will get adopted.

 

3 hours ago, Demz said:

wonder if Mozilla will release a Preview Releases of it before its officially released to the public

Like in a nightly build or beta release?

2 hours ago, The_Decryptor said:

When Firefox initially was released one of the criticisms was that it looked too much like IE6 (And that it "stole" tabs from Opera). All browsers feed off each other (They all do the same job) and it shouldn't be surprising, a good UI design idea is still a good idea, and will get adopted.

 

Like in a nightly build or beta release?

no, something like a UX kinda Preview Release , i would think if Mozilla want Extension Devs to stay there gonna have to release something to allow the Extension devs something to work with, same as Themes i guess

but this is Mozilla, i dont have much faith in Mozilla nowadays

WebExtensions is already in stable Firefox, they don't need any special preview build.

 

Themes iirc are re-using the "LWT" model which Firefox has used for ages, not full blown themes but with the changes they want to make to the UI they wouldn't really cross over anyway (Themes are XUL, the new Firefox UI isn't)

 

Edit: Not really sure I agree with them completely removing full blown themes (they might make a comeback in the future), but in the near term no theme would cross over without an entire re-write anyway, so they can use it as an excuse to make a nicer theming API that won't hurt end users ("Safe Mode" shouldn't need to be a thing, that's the whole reason Mozilla is making these changes).

Quote

 

Mozilla has just audited Tab Mix Plus in order to figure out what part of it functionality is possible to implement using WebExtensions:
https://bugzilla.mozilla.org/show_bug.cgi?id=1333837#c9

It looks like the fate of Tab Mix Plus WebExtension depends on these three bugs right now:

hiding the default tab toolbar - https://bugzilla.mozilla.org/show_bug.cgi?id=1332447
re-implementing tab toolbar using Toolbar API - https://bugzilla.mozilla.org/show_bug.cgi?id=1215064
styling individual tabs - https://bugzilla.mozilla.org/show_bug.cgi?id=1320585


I want Tab Mix Plus to survive so much :oops:

 

 

Photon Mock up of the changes to Customize mode as part of the upcoming design refresh

 

ljjlqb4.jpg

 

 

 

There is some discussion about that here. As I understand it, they aren't going for a separate development branch, and most changes will land gradually as they are ready. The more noticeable ones might be behind prefs or build system trickery.

Looking at the mock up (yes I know a lot could change by the time FF 57 lands on Release), it seems to me that the devs are creating empty space on the left side of the URL bar, and (possibly) forcing users to click on an overflow icon to access icons that no longer fit on the right side

If you remove that empty space, then the only time you would be forced to use the overflow icon is when you have resized the window to be too tiny. So then exactly the same behaviour you have in FF right now.

n6mRHw4.png

 

 

 

bpwxcVo.png

 

 

4Req605.png

 

 

 

So looks like they are going to merge bookmark, history and download panels.

The main problem right now is bookmarks now taking two clicks to get to (three+ clicks to fully use). That's a really annoying increase for a feature that's likely used very often. I didn't see a bookmarks button in Customize either.

Edited by Lyraull
  • Like 7
Quote
  • DOM.  In the DOM team there are several plans and projects under way which will hopefully bring various performance improvements to the browser.  Probably the largest one is the upcoming plans for cooperative scheduling of tasks, which will allow us to interrupt currently executing JavaScript on background pages in order to service tasks belonging to foreground pages.  You may have seen patches landing as part of a large effort to label all of our runnables.  This is needed so that we can identify how to schedule tasks cooperatively.  We are planning to also soon do some work on throttling down timeouts running in background pages more aggressively.  More details will be announced about all of these projects very soon.  Furthermore we are working on smaller scale performance improvements in various parts of the DOM module as new performance issues are discovered through various benchmarks.
  • JavaScript.  In the JavaScript team there have been several streams of work ongoing to work on various improvements to the various aspects of our JS execution.  Jan de Mooij and colleagues have been running the CacheIR project for a while as an attempt to share our inline caches (ICs) between the baseline and Ion JIT layers.  This helps with unifying the cases that can be optimized in these JIT layers and has been showing meaningful improvements both on real web pages and benchmarks such as Speedometer.  They have also been looking at various opportunistic optimizations that also help performance issues we have identified through profiling as well.  Another line of investigation in the JS team for a while has been looking into this bug.  We have some evidence to suggest that our JIT generated code isn’t very efficient in terms of the CPU instruction cache usage, but so far that investigation hasn’t resulted in anything super conclusive.  Another extensive discussion topic was GC scheduling.  Right now the way that our GC (and cycle collection) scheduling works is pretty dis-coordinated between SpiderMonkey and Gecko, and this can result in pathological cases where for example SpiderMonkey sometimes doesn’t know that a specific time is an unfortunate time to run a long running GC, and Gecko doesn’t have a good way to ask SpiderMonkey to stop an ongoing GC if it detects that now would be a good time to do something else, etc.  We’re going to start to improve this situation by coordinating the scheduling between these two parts of the browser.  This is one of those architectural changes that can have a pretty big impact also in the longer term as we find more ways to leverage better coordination.  Another topic that was discussed was improving the performance of our XRay wrappers that provide chrome JS code access to content JS objects.  This is important for some front-end code, and also for the performance of some Web Extensions.
  • Layout.  In the Layout team, we are focusing on improving our reflow performance.  One challenge that we have in this area is finding which reflow issues are the important ones.  We have done some profiling and measurement and we have identified some issues so far, and we can definitely find more issues, but it’s very hard to know how much optimization is enough, which ones are the important ones, and whether we know of the important problems.  The nature of the reflow algorithm makes it really difficult to get really great data about this problem without doing a lot of investigation and analysis work, and we talked about some ideas on what we can do to improve our work flows, but nobody seemed to have any million dollar ideas.  So at the lack of that we won’t be waiting for the perfect data to arrive and we’ll start acting on what we know about for now.  Through looking at many reflow profiles, we have also developed some “intuitions” on some patterns on the types of expensive things that typically show up in layout profiles, which we are working on improving.  There are also some really bad performance cliffs that we need to try to eliminate.
  • Graphics. In the Graphics team, we are planning to make some performance improvement to display list construction by retaining and incrementally updating them instead of reconstructing them every time.  This is an extremely nice optimization to have since in my experience display list construction is the bottleneck in many of the cases where we suffer from expensive paints, and it seems like we have telemetry data that confirms this.  The graphics team is also looking into doing some optimizations around frame layer building and display list building based on measurements highlighting places where things could be improved.

 

  • Like 6
13 minutes ago, Lyraull said:

The main problem right now is bookmarks now taking two clicks to get to (three+ clicks to fully use). That's a really annoying increase for a feature that's likely used very often. I didn't see a bookmarks button in Customize either.

This annoys me with Chrome too (which is what I use) yes, there are extensions for it, but they almost all don't look great and don't feel native to the browser.

 

Chrome still misses easy access bookmarks (without resorting to the "bookmarks bar") and a address bar download manager (using this atm)

  • Like 2
Quote

 

 

 

Edited by Lyraull
  • Like 6
19 minutes ago, Steven P. said:

This annoys me with Chrome too (which is what I use) yes, there are extensions for it, but they almost all don't look great and don't feel native to the browser.

 

Chrome still misses easy access bookmarks (without resorting to the "bookmarks bar") and a address bar download manager (using this atm)

It is currently two clicks to use a bookmark -- Toolbar button > choose bookmark

With the library the process is three clicks -- Toolbar button > Bookmarks > choose bookmark

hope they give us a dedicated browse bookmarks button

 

there still is going to be a search box! and it seems like you can make the location bar full width if you remove the flexible spaces

and some negative is mostly not being able to customize the main menu.

3 hours ago, Demz said:

RIP Firefox, Great knowing you or using you before you turned to ****

Yo, excuse me for the way I'll speak, but can you stfu already? Every comment of yours tilts me(and I'm sure other members). This negativity is not worthy my time checking this thread for info or a decent conversation. Thanks.

  • Like 3
2 hours ago, Boo Berry said:

The mockups are really not that bad at all, actually. I've seen way, way worse.

Probably from Stephen Horlander at time of Australis. :-p

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now