6 ms·

I understand the point, but I think there is a reality where developing and actually experiencing the product can be fundamentally different. For instance the

by hrktb 12y ago

I understand the point, but I think there is a reality where developing and actually experiencing the product can be fundamentally different. For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel. Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite. As you mention, settings in the developer tools could allow a myriad of options to switch from a "user" mode to a "developer" mode. But honestly I'd understand if it happens to be easier to build two different applications, even just for keeping the "user" side code simple enough to make it easy to maintain and secure. Then eventually bundle the two apps together if you want to keep the "tools" right next to the "viewers".

justcommenting 12y ago
These are great points but also speak to one of my concerns about forking--what if Firefox continues to receive lots of security scrutiny but this new-but-still-pretty-intimately-related product aimed at devs mostly doesn't, for whatever reason (e.g. far fewer people using it)? I see more value for both developers and users currently because it means that in order to keep Firefox safe (for some definition of safe), the Mozilla security team also has to keep people like us--and the functionality we use--just as safe. It also means derivatives like the Tor Browser Bundle and Iceweasel might be more likely to preserve the feature set and benefit from security team's work in relation to it.
mariusandreiana 12y ago
>For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel. https://code.google.com/p/chromium/issues/detail?id=328026 https://code.google.com/p/chromium/issues/detail?id=328026 >Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite. Chrome Inspector -> [x] Disable cache (while DevTools is open)
- callahad 12y ago
  Or Firefox Dev Tools -> Settings -> [x] Disable Cache (when toolbox is open) :)
  - azernik 12y ago
    I suspect a lot of the "dev edition" will just be a different set of defaults :)
- james-skemp 12y ago
  A fellow developer in my office uses Incognito mode, and it seems to work fine for him.
  - panzi 12y ago
    That reminds me: It would be nice if you could open several different incognito windows, each with their own session. That way one can debug user interactions without needing as many browsers as users in the interaction (or half of it because each browser has it's own incognito session in addition to the normal session).
    - iamdanfox 12y ago
      A workaround that I've used before is to connect to my site via the domain name in one tab, and the IP address in another - cross domain protection ensures I get two nicely partitioned sessions.
      - panzi 12y ago
        Yep, I also used that. And several entries in /etc/hosts.
- hrktb 12y ago
  > https://code.google.com/p/chromium/issues/detail?id=328026 https://code.google.com/p/chromium/issues/detail?id=328026 Interesting. I think there is also a plugin for WebStorm to send back modification made in the style panel to the actual files. Sadly sass/less resources makes it difficult to edit CSS and have it applied back to the sass source for instance. > Chrome Inspector -> [x] Disable cache (while DevTools is open) Yes, that's what I use for all my projects. Also there is a "Disable Caches" option in the Develop menu of Safari.
Joeri 12y ago
I don't quite see it that way. > For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel. I don't see any inherent conflict between preventing sites from having access to the local filesystem, while having powerful local filesystem access from the browser's integrated devtools. One does not exclude the other. > Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite. Caching rules should be managed on the server, not the client. Properly configured servers/applications never need anyone to clear their caches explicitly. I don't see why you would need a special cache-less mode in the browser if you've set up your servers correctly. In my view developer modes (in browser or framework) are counterproductive because they create discrepancies between how your users experience your site or app and how you experience it. Your browser should have the exact same app experience as the one your users use, so it shouldn't have any special developer-mode behavior. That doesn't mean you don't need powerful inspection tools, just that those tools should be built around that standard experience instead of altering it.
- azernik 12y ago
  WRT caching, the experience of a developer is already completely different from that for a user - assets on a dev instance of you infrastructure (including both code and static files) are changing multiple times a minute.
  - Joeri 12y ago
    I don't think that should necessarily be the case. By persisting resources in the cache after they are changed on the server there is an implicit promise of broken user experiences, since there is no control over which files are loaded from cache and which ones are not (so even for "harmless" images users will see mismatched artwork in the real world). Whatever caching strategy is used for production servers, it should involve a way to make sure users are fetching the latest version of a resource. The dev server can be configured identically and it will still do the right thing. Admittedly when you throw CDN's and other intermediates into the mix it becomes harder to have matching environments, but differences should be minimized as much as possible as a matter of development policy. My dev server is set up identically to a production server, except that no concatenation or minification is done. I'm not happy with that last compromise, so fingers crossed that HTTP/2 gets here soon and we can stop concatenating, minifying and otherwise perverting our code and resources.
octref 12y ago
A live example: If you are developing a chrome extension on Windows, everytime you open Chrome you'd be bugged with a popup which suggests "Disable Developer Mode Extensions". [1] Although developers are annoyed as hell, the Chrome team insisted this decision on the ground of protecting users. [1] https://code.google.com/p/chromium/issues/detail?id=337734 https://code.google.com/p/chromium/issues/detail?id=337734
- astrocat 12y ago
  Their point is entirely valid though, and it all boils down to: there is no such thing as a secure backdoor.

by hrktb 12y ago

justcommenting 12y ago

These are great points but also speak to one of my concerns about forking--what if Firefox continues to receive lots of security scrutiny but this new-but-still-pretty-intimately-related product aimed at devs mostly doesn't, for whatever reason (e.g. far fewer people using it)? I see more value for both developers and users currently because it means that in order to keep Firefox safe (for some definition of safe), the Mozilla security team also has to keep people like us--and the functionality we use--just as safe. It also means derivatives like the Tor Browser Bundle and Iceweasel might be more likely to preserve the feature set and benefit from security team's work in relation to it.

mariusandreiana 12y ago

>For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel. https://code.google.com/p/chromium/issues/detail?id=328026 https://code.google.com/p/chromium/issues/detail?id=328026 >Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite. Chrome Inspector -> [x] Disable cache (while DevTools is open)

callahad 12y ago
Or Firefox Dev Tools -> Settings -> [x] Disable Cache (when toolbox is open) :)
- azernik 12y ago
  I suspect a lot of the "dev edition" will just be a different set of defaults :)
james-skemp 12y ago
A fellow developer in my office uses Incognito mode, and it seems to work fine for him.
- panzi 12y ago
  That reminds me: It would be nice if you could open several different incognito windows, each with their own session. That way one can debug user interactions without needing as many browsers as users in the interaction (or half of it because each browser has it's own incognito session in addition to the normal session).
  - iamdanfox 12y ago
    A workaround that I've used before is to connect to my site via the domain name in one tab, and the IP address in another - cross domain protection ensures I get two nicely partitioned sessions.
    - panzi 12y ago
      Yep, I also used that. And several entries in /etc/hosts.
hrktb 12y ago
> https://code.google.com/p/chromium/issues/detail?id=328026 https://code.google.com/p/chromium/issues/detail?id=328026 Interesting. I think there is also a plugin for WebStorm to send back modification made in the style panel to the actual files. Sadly sass/less resources makes it difficult to edit CSS and have it applied back to the sass source for instance. > Chrome Inspector -> [x] Disable cache (while DevTools is open) Yes, that's what I use for all my projects. Also there is a "Disable Caches" option in the Develop menu of Safari.

Joeri 12y ago

I don't quite see it that way. > For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel. I don't see any inherent conflict between preventing sites from having access to the local filesystem, while having powerful local filesystem access from the browser's integrated devtools. One does not exclude the other. > Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite. Caching rules should be managed on the server, not the client. Properly configured servers/applications never need anyone to clear their caches explicitly. I don't see why you would need a special cache-less mode in the browser if you've set up your servers correctly. In my view developer modes (in browser or framework) are counterproductive because they create discrepancies between how your users experience your site or app and how you experience it. Your browser should have the exact same app experience as the one your users use, so it shouldn't have any special developer-mode behavior. That doesn't mean you don't need powerful inspection tools, just that those tools should be built around that standard experience instead of altering it.

azernik 12y ago
WRT caching, the experience of a developer is already completely different from that for a user - assets on a dev instance of you infrastructure (including both code and static files) are changing multiple times a minute.
- Joeri 12y ago
  I don't think that should necessarily be the case. By persisting resources in the cache after they are changed on the server there is an implicit promise of broken user experiences, since there is no control over which files are loaded from cache and which ones are not (so even for "harmless" images users will see mismatched artwork in the real world). Whatever caching strategy is used for production servers, it should involve a way to make sure users are fetching the latest version of a resource. The dev server can be configured identically and it will still do the right thing. Admittedly when you throw CDN's and other intermediates into the mix it becomes harder to have matching environments, but differences should be minimized as much as possible as a matter of development policy. My dev server is set up identically to a production server, except that no concatenation or minification is done. I'm not happy with that last compromise, so fingers crossed that HTTP/2 gets here soon and we can stop concatenating, minifying and otherwise perverting our code and resources.

octref 12y ago

A live example: If you are developing a chrome extension on Windows, everytime you open Chrome you'd be bugged with a popup which suggests "Disable Developer Mode Extensions". [1] Although developers are annoyed as hell, the Chrome team insisted this decision on the ground of protecting users. [1] https://code.google.com/p/chromium/issues/detail?id=337734 https://code.google.com/p/chromium/issues/detail?id=337734

astrocat 12y ago
Their point is entirely valid though, and it all boils down to: there is no such thing as a secure backdoor.