Talk:Firefox/Namoroka/Initial Plan

From MozillaWiki
Jump to: navigation, search

shaver

  • what is "aggressive use of connection pre-caching"?
    • added notes to help explain -- beltzner
  • what is "cache entropy on crash"?
    • added notes to help explain -- beltzner
  • we already have two types of offline data storage for web developers (localStorage and the resource cache) -- what else is specifically required for Namoroka?
    • removed -- beltzner
  • what sorts of user interface animations need to be supported? affine transformations? all CSS properties? custom blending or processing?
    • this will be determined in the exploration phase -- beltzner
  • has the "no new features after beta1" plan been proposed to platform developers?
    • not outside of this document -- beltzner

Artir

  • And what about Linux integration?
  • GNOME key-manager, Notify-OSD for notifications, for example.
  • KDE integration is a much-requested, but sadly inexistent feature.

MacMel

  • The user interface must be part of alpha test/feedback, beta is really too late.
    • Agreed. Under this plan there will be many alpha milestones which will contain user interface iterations based on the various prototypes, but that will solidify by the time we reach beta. During beta, small changes to the user interface will be permitted, but only due to wider feedback. Beltzner 14:53, 1 April 2009 (UTC)
  • Test-case development should be started in conjunction with the writing of the functional specifications.

DougT

  • Both windows 7 and snow leopard will have location services. Our geolocation implementation should make use of these system services.
    • KDE on Linux is also is the process of creating a geolocation service, scheduled for 4.4, afair.

jwatt

Perhaps a couple of small tweaks:

  • s/intended release target/tentative release target/
  • s/properly investing time/best investing our time/

nth10sd

  • For the Performance goal, Mozmill scripts may be a good ways getting performance numbers per actual use by an end user. Examples include:
    • Opening 1,000 tabs and visiting sites in each. (while not common, there _are_ folks who use an insane number of tabs - and there have been reports of lagginess or similar when there is such a large number of tabs)
    • Going to random sites in hundreds of tabs, along with opening bookmark windows etc., while not restarting Firefox for a certain number of days.
    • Or something similar.
    • Reference at mozmill-dev thread.

Nathaniel

I love the Task Based Navigation idea, and especially the tab grouping aspect. Along those lines, I think my concept Tab Grouping might be an interesting starting point for conceptualizing what this will entail. I look forward to your feedback.

Security

A few security-related suggestions:

  • Windows
 * Support Vista and Windows 7 64-bit systems
 * 64-bit executable runnable with HW DEP and ASLR
 * Optimized for Core 2 Duo and later Xeons with 64-bits, NX, SSE2, SSE3, SSSE3
  • MacOS X
 * Support Leopard and Snowleopard 64-bit systems
 * 64-bit executable supporting all snowleopard security features (still hazy?)
 * Optimized for Core 2 Duo and later Xeons with 64-bits, NX, SSE2, SSE3, SSSE3
  • Linux
 * Support 64-bit versions
 * 64-bit executable
 * Support whatever security is generally available
 * Optimized for Core 2 Duo and later Xeons with 64-bits, NX, SSE2, SSE3, SSSE3
  • Although some code may slow down ~10% with longer addresses, use of the XMM registers greatly speeds up some code as well. Overall, I would expect performance to be about the same based on other benchmarks. Not everyone will be able to run these binaries, but, IE8 on Vista 64 already has these enhancements, and I would hate to see Firefox not have them available.

blizzard

  • I've heard a lot of good feedback on the chrome download manager - can we spend some time during the prototyping period to look and see if we can make some improvements?

Adam757

  • IEAK style administration kit, allowing flexible, locked-down settings deployment for corp. environments

johnath

skierpage

pay little attention, just a user :-)

Re [P2] support file management tasks (delete, move, etc) in download manager

I think the Download manager should be another view in Places (the Library window). Places should remember info about URLs you've saved, and then turn around and let you view and manage the local file://path URLs to which you've saved/downloaded. Tagging, starring, viewing information about downloads such as when saved, the URL you downloaded and the URL of the page where you downloaded; all have a natural fit with Places data.

How are you going to support file move/copy management? You could give Places yet another view, a file system view similar to Windows Explorer. Already its navigation pane looks almost identical to Explorer Bar > Folders view in Windows. It might be natural to organize local file:// URLs by showing the directory structure into which you downloaded them.

Talk is cheap, but I'll try to flesh out these ideas at User:Skierpage/Places as a next-gen file manager

-- Skierpage 01:27, 13 May 2009 (UTC)

a single XULRunner

I think the vision of a suite of Mozilla-powered apps (e.g. Firefox, Thunderbird, Songbird, Miro, a few Prism apps) sharing a single XULRunner is still compelling, particularly for constrained environments like set-tops/netbooks/instant-on like SplashTop. Firefox in isolation is losing out to WebKit on some of those devices (Rest In Peace "Firefox Tablet"), but WebKit does not make a platform. Even if Mozilla's products and other "Powered by Mozilla" projects are only delivered as XULRunner apps on Linux.

-- Skierpage 05:04, 6 June 2009 (UTC)

Handle more stuff in the browser

Firefox is too willing to hand off to other, often-worse or non-existent applications for functions such as viewing text or archives, and it's hard to change its behavior.

Low-hanging fruit:

  • Provide "View in browser as text" for unrecognized mime types and anything that might be text (a bit like bug 327323 and bug 218257)
  • Expose the awesome jar: protocol for browsing compressed .ZIP archives (and ODF files) (bug 502528)
  • Other bugs in Firefox's File handling category.

-- Skierpage 02:25, 6 July 2009 (UTC)

Mute Background Music

Sometimes we visit websites with a background music which we can not control unless we lower or mute the sound from the master control. I think it will be useful if we can mute that sound without affecting the sound coming from the other tabs and windows of FireFox.

-- Ahmed-Linux 22:32, 27 May 2009

This is a pioneering thing... Once someone supports this it´ll become SO ESSENTIAL we´ll ask why we didn´t do it sooner.

  • It should work like this:
    • No song playing -- normal tab
    • Song playing -- Add the traditional sound icon
      • Whatever the source (<video>, <audio>, flash, silverlight, etc) the audio MUST be detected **MAGIC NEEDED HERE**
    • Song muted -- Add the traditional muted icon

Obs: Of course the icons should be Firefox style not tango

--Goolic 00:25, 4 July 2009 (UTC)

Electrolysis

It seems that Electrolysis is planned within the same timeframe as 3.6's development process. If all goes well, will it be seen in Namoroka? --RayneVanDunem 17:46, 29 May 2009 (UTC)

Tabs on Top, UI, sandboxing, ripping tabs.

I recently was briefly converted to Safari when it was in beta with the Tabs on Top. I've switched back now that Apple have put the tabs 'back where they belong'. Could there at least be the option to have Tabs on Top in Firefox.next?

Another little thing from Safari 4 is the Top Sites page - I think the new "New Tab" page should definately have some eye-candy like that!

Thirdly, this is probably for some time beyond Namoroka, but there is an article in this month's PCPro magazine (I can't find it published online - I think there's a delay to get you to buy the mag), which is about next-generation browser UI. In essence, the author suggests that browser interface should adjust according to the site you are on. For example, it might detect that you are using a self-contained app like Gmail or Facebook and automatically strip back on toolbars. Or maybe use some kind of Office-2007-esque ribbon.

Finally, I'm not sure if this is already implemented in 3.5b4, but is sandboxing tabs a possibility? It's one of the reasons I've been wanting Google to make a Mac-version of Chrome.

And the way you can rip tabs out of windows in 3.5 isn't quite satisfactory if you've been using Safari 4. Dragging the tab out onto a second screen should form the new window on that screen, also I think that pages are re-loaded when their tab is moved between windows? This can muck up JavaScript/Flash stuff, but it's just another thing I liked from Safari...

This is just my personal wishlist for Firefox.next, which I would be absolutely useless at implementing, as I haven't got the first clue how to do desktop development, just PHP and stuff for me!

THANK YOU to all the wonderful people who make Firefox! I look forward to Firefox3.6a1!

Isaac

dolske

I think we should make a top-level (or at least upper-level) item for refreshing the theme / interface with a big stick. Not just the usual incremental changes and hygiene, but really making a concerted effort to remove clutter, simplify and unify, and make things look well-integrated and beautiful in comparison to things like Chrome and Safari. Also to front-load some of these things, so that it's not all a final rush at the end of the cycle when it's too late to make big changes.

Cww

Really small thing to implement (I hope) but big help: get a Help > Troubleshooting Data (or however you want to call it, Diagnostic data, technical data for support techs). This will have list of extensions, recent crashIds plugins and links to sumo things (maybe). The idea is that it should be copy-pasteable to SUMO or some other tech support service for fast help.

pij

I wish the browser would provide some infrastructure to cope with equivalent URLs/bookmarks. -- User:pij, 21:44, 3 July 2009

The Problem

It is quite common to get via different URLs to same content. This can happen for various reasons:

Furthermore, there are sets of URLs point to content which are more or less considered the same by most users but is not literally the same, e.g. http://foo vs. https://foo, the latter is more likely to have https:// in hrefs instead of http://, and occasionally there is content specifically for the purpose to help the user to differentiate between the secured and the unsecured version of the content.

The problem is that a user may bookmark the same content using different URLs, and he may end up on a page not marked as bookmarked after opening a bookmark.

As an extension, some users might consider some URLs as related, for example the Sourceforge.net page of a project, its homepage, its freshmeat page etc., and it may be convenient to manage them as a set. While storing the related bookmarks in a folder is certainly a solution, it has to rely on conventions for expressing certain semantics, e.g. that the first bookmark in the folder represents the canonical, or master URL for the set of bookmarks.

Suggestions

I suggest that the browser should provide

  • a mechanism to store named relations between bookmarked URLs
  • a UI for presentation an manipulation of a set of related bookmarks, e.g. "http://foo/stuff redirected from: http://foo/1, http://bar"
  • automatic detection of some common situations and propose a useful action to the user, e.g.
    • asking whether a canonicalized URL should be stored instead of the actual URL
    • asking whether the https URL should be opened instead of the actual http URL

Of course, the browser should have asserted that the content is really equivalent, which may require advanced techniques. An interesting complement to algorithms may be using a browser extension and/or a wiki to crowdsource sets of equivalent URLs.

Extensions could provide more complex functionality, like processing doap files into a set of bookmarks related to the project for fast access to various resources.

Znerd

Printing web pages

The printing of web pages is an area that could use considerable improvement. Rendering pages for display on a screen gets a lot of attention from Mozilla developers and the end result, Gecko, works great in this respect.

However, printing seems to get a lot less attention. It would be nice if, for example, the printing-related CSS properties would get a decent review, improvements where needed and some automated tests.

For more information, see:

Ellipsis on text overflow

Secondly, support for text-overflow: ellipsis (see bug 312156) would be very much welcomed, as this is an example of a minor issue that causes many web developers great grief. A lot of different complex workarounds have been employed just to get around this. Adding native support would really help a lot.

Note: Simon Montagu appears to be working on the bug.

Znerd 09:57, 11 July 2009 (UTC)

CarlosM

Optimize Linux Builds

Linux builds have lower performance than the windows builds even if you run the windows build using Wine. the test I'm doing consist on running the different builds and enter to this link:

This link points to the JavaScript code used to verify the Google Chrome performance.

The score shown may vary on +-5 points from run to run but when compared between different platform builds it may run from 180 on the linux-native build to 240 at the Windows native build.

Note from Chris Blizzard

Carlo - The windows builds are faster because the compiler generally creates better code than gcc does. Plus, afaik, we can't use PGO on Linux because of tooling problems with the profiling tools and threaded applications. We've spent a lot of time optimizing Linux but if you would be willing to help get some gcc people to look at those tools it would help a lot - thanks!

Apparently, Tracemonkey/JIT isn't available for 64bit yet. This would explain why many Linux users have a poor experience, especially with JS benchmarks pointed to by CarlosM. paepse 09:06, 20 August 2009 (UTC)

Samuelspiza

Menu Bar

I really like the option to hide the Menu Bar in 3.6a1. It brings the Interface closer to a point where it only contains features i really need. However i think the handling of the problem could be further improved. With a hidden Menu Bar functions that have no keyboard shortcut are not quite handy to access. (Preferences, Addons, Update, + everything you doesn't do reguarly enough to remember the shortcut)

I have to click twice to undo the hiding. Then at least two clicks to access the function. Finally two more clicks to hide the Bar again. Even if I need functions from the Menu Bar only once or twice a day this procedure feels somehow arbitary complicated.

The prefered solution for me would be an option to hide the menus under a button right next to the home/reload buttons. This Layout would still save many pixels compared to a whole bar. However it would have lower burden to access the features.

First Impressions I Have From a User Standpoint

I'm no tech or anything when it comes to browsers I just know what I like and functionality of them. Can't say how to change stuff or make it better, just know how to see if they work properly for day to day activities with certain add-ons.

I am running Vista Ultimate 64 with the latest updates.

Still running RedShift v3 with no issues (well it may be causing my issues too).

All add-ons that shouldn't work so far seem to be working fine (that I use on a day to day basis).

  • last.fm isn't working (but shouldn't and just noticed)

Having issues adding Bookmarks (they won't) and all my saved bookmarks didn't transfer over (probably have to do something else but unsure what atm).

Doesn't seem to eat memory like 3.5.2 does or hold on in the system after it was closed.

Also doesn't seem to use the processor up like 3.5.2 did instead seems to be taking less.

The memory seems to pretty much stay stable the whole time also.

Overall seems more stable then 3.5.2

Running Quad Extreme Q9650, 4GB 1066MHz RAM, on a 780i MB, with Raptor HDD, under Vista Ultimate 64.

Current benchmarks of browsers I currently have installed (used peacekeeper for test http://service.futuremark.com/peacekeeper/index.action). I only did one run per browser but the numbers are far enough apart to make the point.

Minefield 3.7a1pre - 2578 (22 Aug) 2216 (24 Aug)

Namoroka 3.6a1 - 2441

Firefox 3.5.2 - 2036

Chrome 3.0.195.6 - 3829

IE 8.0.6001.18813 - 868

IE 8.0.6001.18813 64-bit - 881

Chrome still wins even in Sunspider test at 507ms on my setup.

Minefield is close behind too with 796.6 (22 Aug) 933.2 (24 Aug) so they've already taken over 100ms off between an alpha and pre-alpha release. I believe Firefox can squeak out past everyone shortly. Also see the jump from 3.6 to 3.7 soon with Minefields marks.

Minefileld is getting worse actually in marks. Haven't tested 3.5.3 yet nor 3.6a2pre.

Sunspider Test between 3.5.2 (left) and 3.6a1 (right)

TEST COMPARISON FROM TO DETAILS

=================================================================
    • TOTAL **: 1.27x as fast 1228.4ms +/- 3.6% 970.0ms +/- 2.0% significant
=================================================================
 3d:                  -                  176.2ms +/- 13.2%   154.6ms +/- 7.3% 
   cube:              1.29x as fast       51.2ms +/- 3.6%    39.6ms +/- 13.4%     significant
   morph:             -                   55.2ms +/- 20.2%    55.0ms +/- 1.6% 
   raytrace:          -                   69.8ms +/- 25.7%    60.0ms +/- 18.3% 

 access:              -                  146.4ms +/- 9.3%   131.8ms +/- 14.7% 
   binary-trees:      -                   41.8ms +/- 19.7%    39.6ms +/- 16.7% 
   fannkuch:          -                   61.6ms +/- 19.4%    55.4ms +/- 20.8% 
   nbody:             1.20x as fast       28.4ms +/- 2.4%    23.6ms +/- 8.8%     significant
   nsieve:            -                   14.6ms +/- 11.4%    13.2ms +/- 32.2% 

 bitops:              -                   40.2ms +/- 10.1%    38.8ms +/- 3.5% 
   3bit-bits-in-byte: 1.25x as fast        2.0ms +/- 0.0%     1.6ms +/- 42.6%     significant
   bits-in-byte:      1.04x as fast       10.0ms +/- 0.0%     9.6ms +/- 7.1%     significant
   bitwise-and:       ??                   2.2ms +/- 25.3%     2.8ms +/- 19.9%     not conclusive: might be *1.27x as slow*
   nsieve-bits:       -                   26.0ms +/- 17.6%    24.8ms +/- 2.2% 

 controlflow:         -                   42.8ms +/- 9.7%    39.6ms +/- 14.8% 
   recursive:         -                   42.8ms +/- 9.7%    39.6ms +/- 14.8% 

 crypto:              1.36x as fast       67.6ms +/- 4.2%    49.6ms +/- 13.3%     significant
   aes:               1.38x as fast       40.4ms +/- 3.5%    29.2ms +/- 22.8%     significant
   md5:               1.37x as fast       17.0ms +/- 17.9%    12.4ms +/- 5.5%     significant
   sha1:              1.27x as fast       10.2ms +/- 5.5%     8.0ms +/- 0.0%     significant

 date:                1.28x as fast      203.6ms +/- 7.4%   159.0ms +/- 14.3%     significant
   format-tofte:      1.40x as fast      106.2ms +/- 6.3%    75.8ms +/- 19.4%     significant
   format-xparb:      1.17x as fast       97.4ms +/- 10.9%    83.2ms +/- 16.8%     significant

 math:                1.10x as fast       60.2ms +/- 1.7%    54.8ms +/- 8.2%     significant
   cordic:            1.15x as fast       34.4ms +/- 2.0%    30.0ms +/- 15.5%     significant
   partial-sums:      1.05x as fast       17.6ms +/- 3.9%    16.8ms +/- 3.3%     significant
   spectral-norm:     -                    8.2ms +/- 6.8%     8.0ms +/- 0.0% 

 regexp:              1.57x as fast      109.4ms +/- 9.5%    69.8ms +/- 20.1%     significant
   dna:               1.57x as fast      109.4ms +/- 9.5%    69.8ms +/- 20.1%     significant

 string:              1.40x as fast      382.0ms +/- 5.5%   272.0ms +/- 6.2%     significant
   base64:            1.27x as fast       19.0ms +/- 0.0%    15.0ms +/- 19.4%     significant
   fasta:             1.59x as fast       87.8ms +/- 1.8%    55.2ms +/- 19.5%     significant
   tagcloud:          1.13x as fast       96.8ms +/- 10.0%    85.6ms +/- 8.4%     significant
   unpack-code:       1.65x as fast      138.0ms +/- 17.8%    83.8ms +/- 14.0%     significant
   validate-input:    -                   40.4ms +/- 19.4%    32.4ms +/- 16.4%

jacekmw

Windows 7 Jump Lists

Currently, the Windows 7 Jump List functionality can be obtained for Firefox with WinFox, but it would be useful for a standard install to have this. The Pinned/Frequent/Tasks model WinFox uses would work well, and would mirror the way jump lists are used for many native Windows apps (IE8, WMP, etc)

ggoo

Currently when restarting Firefox, if one has it configured to restore windows from a previous session, any pages with POST data will display a sheet explaining that the data must be resent to redisplay the page. This is of course necessary any time one wants to redisplay a POSTed page, and the decision must be available to the user. There are two problems I will address about this feature, one with what appears to be the current plan to change it, and the other, a problem with the current behavior.

I see at <https://wiki.mozilla.org/Firefox3/Product_Requirements_Document> at item "GKO-002a" that this sheet (as it's displayed under Mac OS X, at least) is apparently going to be changed to an error page! This could be a big disappointment, as it would seem to mean one would lose all the forward history in the window or tab! It might be that this should be an optional setting, but it shouldn't be mandatory for those of us who like to be able to retain the forward history.

The other problem with the message is not normally an issue when one is using the Back button to navigate to a page that needs reloading, but is a problem when one is restoring a window with several tabs. In the latter case the message dialog sheet obscures the URL field in the address bar, so one can't tell what page one is being asked to resend data for. This leaves one in the awkward position of either guessing what page it is, or just declining to reload all pages initially, in which case one gets an error page for each of them, and loses all the forward history for each such tab, which as I explained above, I often wish to retain. If the dialog message were simply elaborated to include the URL (and possibly the original title, if it is saved between sessions) of the page that needs reloading, then a better decision could be made by the user.

So please retain the modal dialog type of notification (such as a sheet) for pages that require POST data to be resent, at least as an option, but modify the dialog to be explicit as to the URL receiving the data (since that's the page to be displayed), and possibly the URL sending the data as well, if they differ significantly.

Ggoo 02:12, 29 August 2009 (UTC)

Retrieved from "https://wiki.mozilla.org/index.php?title=Talk:Firefox/Namoroka/Initial_Plan&oldid=165136"