Closed Bug 852490 Opened 11 years ago Closed 11 years ago

‘Web Developer’ tools should have a content toggle menu.

Categories

(DevTools :: General, defect)

21 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: beta, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20130318 Firefox/21.0
Build ID: 20130318042013

Steps to reproduce:

With Bug 851701 & Bug 851702, useful developer options are likely to be removed from the user-facing preferences system.

Could possibly relocate them onto a menu in the developer menu, and even put the now invisible page styles menu back in with this.

* Allow Images ☑
* Allow JavaScript ☑
* Allow Styles ☑ -> * %css names%
                               * %other css name%
OS: Linux → All
Hardware: x86_64 → All
Component: Untriaged → Developer Tools
Just looking at the size of this menu, any additions are going to make it too long:
Web Console, Inspector, Debugger, Style Editor & Profiler all have their own menu item, even though they can be shown with the ‘Toggle Tools’ item. It’s probably worth removing them, bumping the current options to their place, and placing these new items below along with the encoding menu.
Attached image Initial appearance
What I’ve done, removed five developer tool menu items reachable via toggle tools, added Allow JavaScript, Allow Images and the Page Style menu.

Would love to remove ‘No Style’, change Page Style to be a checkbox like ‘Allow …’ and maybe have the submenu present only if more than one page style exists.

Just got to find the best place to put some javascript for the toggle js+img routines.
One useful feature of keeping the toolbox tools in the menu is that it teaches the user about the keyboard shortcut for the tools. Not a must-have, but useful.

In general, however, we have been trying to remove stuff from menus, not add more. Since I do agree that keeping these additional toggles is useful for web developers, I think that a good solution would be to put them in the options tab from bug 851546. How does that sound?
I like Panos's idea. Optimizer/Paul what do you think?
(In reply to Joe Walker [:jwalker] from comment #4)
> I like Panos's idea. Optimizer/Paul what do you think?

Sure, there is always room for another item in the left menu, or even inside the current "Under the hood settings" label (where devtools.chrome.enabled and devtools.debugger.remote-enabled lie).
Stephen, do yo know what was going to happen to this menu item under Australis? I'm kind of assuming that we were just going to ditch it, which probably means that this patch will cause breakage in the UX branch, so perhaps we might be better off just adding it to the options panel for now (if that's what we decide)

Also, worth thinking about: I can't see where other browsers do this, it does seem useful though. Am I missing something - didn't everyone do this a while ago?
(In reply to Panos Astithas [:past] from comment #3)
> One useful feature of keeping the toolbox tools in the menu is that it
> teaches the user about the keyboard shortcut for the tools. Not a must-have,
> but useful.

Yes, it’s very useful, but with the current state of the menu, there are 6 menu items in a row that solely change tab in the toolbox that should already be visible. Could shortcuts become a part of the tab tooltip in the toolbox?

> In general, however, we have been trying to remove stuff from menus, not add
> more. 
This removed two! And makes for a quicker dev workflow… and gives the UX guys room to tidy up preferences. 

> Since I do agree that keeping these additional toggles is useful for
> web developers, I think that a good solution would be to put them in the
> options tab from bug 851546. How does that sound?

If this bug isn’t favoured, it does not sound terrible. But, that increases the amount of clicks to toggle these settings over the current preferences option.


(In reply to Joe Walker [:jwalker] from comment #6)
> Also, worth thinking about: I can't see where other browsers do this, it
> does seem useful though. Am I missing something - didn't everyone do this a
> while ago?

Opera 12’s View menu has access to these preferences, Chrome may have had something but it changes so much I may be wrong.
> (In reply to Joe Walker [:jwalker] from comment #6)
> > Also, worth thinking about: I can't see where other browsers do this, it
> > does seem useful though. Am I missing something - didn't everyone do this a
> > while ago?
> 
> Opera 12’s View menu has access to these preferences, Chrome may have had
> something but it changes so much I may be wrong.

Ah, thanks. Will be interesting to see what happens in Opera 13. I'd bet it's gone! I searched Chrome up and down but couldn't see any such setting.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think simply that we should add a preference GUI to devtools' toolbox options panel which is introduced by bug 851546. This is very simple & a sure methods.
Toggle JS seems like a good addition to the options panel, although we need to think about where else in the UI it is (or was? I can't see this now)

I'm not sure what benefit there is in toggling images to a developer. I can see that it could be useful in bandwidth limited situations, but the toolbox options panel is the wrong place for this.

Similarly I'm not sure about a toggle switch for Java. That seems like the job of click-to-play.

I'm not sure about stylesheets. There used to be a point in doing accessibility properly, but I wonder if this is still the case. I'm not clear that our system for switching page styles is valuable though.
(In reply to Joe Walker [:jwalker] from comment #10)
> Toggle JS seems like a good addition to the options panel, although we need
> to think about where else in the UI it is (or was? I can't see this now)

It has already been removed (bug 851702) which earlier was present in Options > Content > Disable JS.

> I'm not sure what benefit there is in toggling images to a developer. I can
> see that it could be useful in bandwidth limited situations, but the toolbox
> options panel is the wrong place for this.
> 
> Similarly I'm not sure about a toggle switch for Java. That seems like the
> job of click-to-play.
> 
> I'm not sure about stylesheets. There used to be a point in doing
> accessibility properly, but I wonder if this is still the case. I'm not
> clear that our system for switching page styles is valuable though.

I agree with Joe, options to disable images is not of a use to a web developer. Same for Java and stylesheets (which btw are/were not even present in the browser itself) .
(In reply to Girish Sharma [:Optimizer] from comment #11)
> (In reply to Joe Walker [:jwalker] from comment #10)
> > Toggle JS seems like a good addition to the options panel, although we need
> > to think about where else in the UI it is (or was? I can't see this now)
> 
> It has already been removed (bug 851702) which earlier was present in
> Options > Content > Disable JS.

Right - you're not arguing that we shouldn't have it though, just explaining why I couldn't find it?
(In reply to Joe Walker [:jwalker] from comment #12)
> (In reply to Girish Sharma [:Optimizer] from comment #11)
> > (In reply to Joe Walker [:jwalker] from comment #10)
> > > Toggle JS seems like a good addition to the options panel, although we need
> > > to think about where else in the UI it is (or was? I can't see this now)
> > 
> > It has already been removed (bug 851702) which earlier was present in
> > Options > Content > Disable JS.
> 
> Right - you're not arguing that we shouldn't have it though, just explaining
> why I couldn't find it?

because I am agreeing with you that we should have it :)
(In reply to Joe Walker [:jwalker] from comment #10)
> I'm not sure what benefit there is in toggling images to a developer. I can
> see that it could be useful in bandwidth limited situations, but the toolbox
> options panel is the wrong place for this.

The web developer uses the option toggling images for check images' alt attribute. It's may be low frequency use-case, but there is a certain demand. I think we should add to its option to devtools option pane. We will not pay the large cost for placing it.
(In reply to Tetsuharu OHZEKI [:saneyuki_s] from comment #14)
> (In reply to Joe Walker [:jwalker] from comment #10)
> > I'm not sure what benefit there is in toggling images to a developer. I can
> > see that it could be useful in bandwidth limited situations, but the toolbox
> > options panel is the wrong place for this.
> 
> The web developer uses the option toggling images for check images' alt
> attribute. It's may be low frequency use-case, but there is a certain
> demand. I think we should add to its option to devtools option pane. We will
> not pay the large cost for placing it.

So we need to weigh up the cost and the benefit of these features. The cost is in things like this:

https://support.mozilla.org/en-US/kb/websites-look-wrong-or-appear-differently#w_reset-the-page-style

Someone clicks it by mistake, and then we need to tell them how to get out of their mess. Now granted developers are less likely to do this, but we still need to be aware.

There are a number of things we could do:

1. Only have these options enabled when the developer tools are open. This includes 'disable JS'.

2. We could also think about solving the 'what are my alt attrs like' problem directly rather than indirectly. Perhaps a 'showalt' command that would highlight the images with alt attribtes, and display them all?
(In reply to Joe Walker [:jwalker] from comment #10)
> Toggle JS seems like a good addition to the options panel, although we need
> to think about where else in the UI it is (or was? I can't see this now)
> 
> I'm not sure what benefit there is in toggling images to a developer. I can
> see that it could be useful in bandwidth limited situations, but the toolbox
> options panel is the wrong place for this.
> 
> Similarly I'm not sure about a toggle switch for Java. That seems like the
> job of click-to-play.
> 
> I'm not sure about stylesheets. There used to be a point in doing
> accessibility properly, but I wonder if this is still the case. I'm not
> clear that our system for switching page styles is valuable though.

"see that it could be useful in bandwidth limited situations"
Certainly is also the java-script(disable) mostly always
even in Corporate environments & not only useful to just web developers but other users like us too


In our company we need to check for certain things(for our customers)
or we are restricted by bandwidth/network load but our work does not require loading pages or JS
so we always need to disable images & JS
would love if we could just add buttons on the addon-bar or make it more accessible in the Menu button>advance>setting(under web developers)>all the advance settings removed by Minimalism project? like chrome has a advance settings menu for people who know what they are doings & can just easily toggle on/off instead of remembering all the entries of about:config

certainly very useful to our 500 or so employees(and one of the main reasons to use FF)

Please think about us too before even thinking of removing this option

:)
(In reply to Joe Walker [:jwalker] from comment #15)
> There are a number of things we could do:
> 
> 1. Only have these options enabled when the developer tools are open. This
> includes 'disable JS'.

I agree it's good for this feature!

> 2. We could also think about solving the 'what are my alt attrs like'
> problem directly rather than indirectly. Perhaps a 'showalt' command that
> would highlight the images with alt attribtes, and display them all?

I agree we may need to add "showalt" command to GCLI. However, at web
development, developer sometimes checks pages without showing images for
accessibility & layout. Only showing alt attributes is not perfectly for this
purpose. We should introduce its feature as possible.

And I agree that Marilyn's comment #16.
(In reply to Marilyn Munster from comment #16)
> (In reply to Joe Walker [:jwalker] from comment #10)
> > Toggle JS seems like a good addition to the options panel, although we need
> > to think about where else in the UI it is (or was? I can't see this now)
> > 
> > I'm not sure what benefit there is in toggling images to a developer. I can
> > see that it could be useful in bandwidth limited situations, but the toolbox
> > options panel is the wrong place for this.
> > 
> > Similarly I'm not sure about a toggle switch for Java. That seems like the
> > job of click-to-play.
> > 
> > I'm not sure about stylesheets. There used to be a point in doing
> > accessibility properly, but I wonder if this is still the case. I'm not
> > clear that our system for switching page styles is valuable though.
> 
> "see that it could be useful in bandwidth limited situations"
> Certainly is also the java-script(disable) mostly always
> even in Corporate environments & not only useful to just web developers but
> other users like us too
> 
> 
> In our company we need to check for certain things(for our customers)
> or we are restricted by bandwidth/network load but our work does not require
> loading pages or JS
> so we always need to disable images & JS
> would love if we could just add buttons on the addon-bar or make it more
> accessible in the Menu button>advance>setting(under web developers)>all the
> advance settings removed by Minimalism project? like chrome has a advance
> settings menu for people who know what they are doings & can just easily
> toggle on/off instead of remembering all the entries of about:config
> 
> certainly very useful to our 500 or so employees(and one of the main reasons
> to use FF)
> 
> Please think about us too before even thinking of removing this option
> 
> :)

Complete agree with this proposal
also
* Allow Images ☑
* Allow JavaScript ☑
should be accessible always ,
*not* only have these options enabled when the developer tools are open
This
includes 'disable JS' 'load images''Advance JS settings'
Really happy to see i am not the only one :) and Hopefully developers Of FF change their mind :)

Could possibly relocate them 'under web developer menu'
into a **Advance menu** instead of in the developer menu as it's easier to access & Most people other than developers use it too,
and even put the now invisible page styles menu back in with this & also the advance JS options.

* Allow Images ☑
* Allow JavaScript ☑
* Allow JavaScript Advance settings ☑-> entries
* Allow Styles ☑ ->* %css names%
                    * %other css name%

Plus the web developer menu will be smaller 
& in the Advance menu all the settings used by power users or Corporates(like us)
who can change easily the required settings mores easily including the above & SSL etc which were removed recently

These settings JS/Images Loading/SSL are used everyday by us :(
& we love FF because it allows us to Toggle them easily w/o diving into piles of hacks of entries

Hope you yous Under stands our sentiments & respect the needs of LOYAL users Thankyou
The web developer menu and the toolbox are not the places where we will solve the problems of corporate environments. I'm not sure where it is, but it's not here. We're solving problems for developers.

I've raised bug 864249 to tackle the disabling of JS, but right now, I don't see a good reason why developers need to toggle styles/images especially at the expense of confusing normal users.
(In reply to Joe Walker [:jwalker] from comment #20)
> I've raised bug 864249 to tackle the disabling of JS, but right now, I don't
> see a good reason why developers need to toggle styles/images especially at
> the expense of confusing normal users.
 
I regularly, as part of checking things my sites for when things fail, use all of these toggles. Which is why I filed this bug suggesting they get added to the developer menu.

The reason the original GUI vanished was that it was a user-changeable setting buried in preferences that could break everything. Bug 864249 suggests to put it into the dev toolbox, this has the same problem.

To make it usable and not prone to the original problem would imo to 1, put them in the dev. menu 2, temporary only for the current tab. 3, make them reset to default on browser load.

> Similarly I'm not sure about a toggle switch for Java. That seems like the job of click-to-play.

Don’t even know who mentioned Java, what was this a reply to?
(In reply to John Drinkwater (:beta) from comment #21)
> (In reply to Joe Walker [:jwalker] from comment #20)
> > I've raised bug 864249 to tackle the disabling of JS, but right now, I don't
> > see a good reason why developers need to toggle styles/images especially at
> > the expense of confusing normal users.
>  
> I regularly, as part of checking things my sites for when things fail, use
> all of these toggles. Which is why I filed this bug suggesting they get
> added to the developer menu.
> 
> The reason the original GUI vanished was that it was a user-changeable
> setting buried in preferences that could break everything. Bug 864249
> suggests to put it into the dev toolbox, this has the same problem.
> 
> To make it usable and not prone to the original problem would imo to 1, put
> them in the dev. menu 2, temporary only for the current tab. 3, make them
> reset to default on browser load.

I think you are being mistaken here. Adding to Developer Toolbox's Options panel is much much less user changeable and prone to the original problem. Keep in mind that most of the normal users would not open Developer tools, but will surely open Firefox's Options Window for some or other thing. Keeping it in Web Developer menu is much more user discoverable than keeping it in the options panel of dev tools. Also, adding more and more menus and sub menus to Web Developer entry in Tools menu should be avoided. You are suggesting 4 level of menus (Tools > Web Developer > Advanced > Allow Styles > (2 entries)) which is not a good UI.
(In reply to Girish Sharma [:Optimizer] from comment #22)

> I think you are being mistaken here. Adding to Developer Toolbox's Options
> panel is much much less user changeable and prone to the original problem.
> Keep in mind that most of the normal users would not open Developer tools,
> but will surely open Firefox's Options Window for some or other thing.
> Keeping it in Web Developer menu is much more user discoverable than keeping
> it in the options panel of dev tools. Also, adding more and more menus and
> sub menus to Web Developer entry in Tools menu should be avoided. You are
> suggesting 4 level of menus (Tools > Web Developer > Advanced > Allow Styles
> > (2 entries)) which is not a good UI.

I am sorry if i was not clear

I meant
Tools > Advanced > Allow * various advance settings

Most people other than developers use it too,
and even put the now invisible page styles menu back in with this & also the advance JS options.
* Allow Images ☑
* Allow JavaScript ☑
* Allow JavaScript Advance settings ☑-> entries
* Allow Styles ☑ ->* %css names%
                    * %other css name%

If you don't find it useful that doesn't mean other people would also
but if its easily toggle-able them i am happy
thankyou
(In reply to Marilyn Munster from comment #23)
> (In reply to Girish Sharma [:Optimizer] from comment #22)
> 
> > I think you are being mistaken here. Adding to Developer Toolbox's Options
> > panel is much much less user changeable and prone to the original problem.
> > Keep in mind that most of the normal users would not open Developer tools,
> > but will surely open Firefox's Options Window for some or other thing.
> > Keeping it in Web Developer menu is much more user discoverable than keeping
> > it in the options panel of dev tools. Also, adding more and more menus and
> > sub menus to Web Developer entry in Tools menu should be avoided. You are
> > suggesting 4 level of menus (Tools > Web Developer > Advanced > Allow Styles
> > > (2 entries)) which is not a good UI.
> 
> I am sorry if i was not clear
> 
> I meant
> Tools > Advanced > Allow * various advance settings

1. Then the status of the bug and the initial mockup attachement are incorrect, so is the component (may be not) :)
2. This makes these settings so easy to be discovered by a general user that now it posses a greater risk than before. Thus applying the "checkboxes-that-kill" rule, these cannot sit in Tools > Advanced :)
3. Adding a first level menu in Tools Menu might require more approvals by front end devs apart from devtools devs.

I am not saying that these options should not be given. In fact there are bug 864249 and bug 864098 and a gcli command proposal to solve "show me alt images" issue for starters to solve the real problem of devs.
(In reply to Girish Sharma [:Optimizer] from comment #24)

> 1. Then the status of the bug and the initial mockup attachement are
> incorrect, so is the component (may be not) :)

sorry just a user & no technical idea of what you said :)

> 2. This makes these settings so easy to be discovered by a general user that
> now it posses a greater risk than before. Thus applying the
> "checkboxes-that-kill" rule, these cannot sit in Tools > Advanced :)

okey so your proposal(in the screen shot) is okay
but advance JS settings are missing (enable/disable  menu etc)

> 3. Adding a first level menu in Tools Menu might require more approvals by
> front end devs apart from devtools devs.

But if it's worth it why not go for it?
alot of useful items can be put there with a warning like about:config?, & normal users won't & usually don't touch the defaults so "checkboxes-that-kill" is out of the question
(chrome has a advance menu for power user stuff too)

> I am not saying that these options should not be given.

Thanks for understanding :)

>In fact there are
> bug 864249 and bug 864098 and a gcli command proposal to solve "show me alt
> images" issue for starters to solve the real problem of devs.

Yes but It's not only the devs who use these features
Normal people like use do too you know :)
I agree and like that we should add the checkbox to toggle enable/disable JS to developer toolbox option pane.

But I doubt that we need to add all JS advanced settings too. I don't seem it provide benefits for web developers. Today, we consider whether or not user environment supports JS when we develop a web. However, we don't wheter the user env support the JS feature which override context menu. It's not common case.
Two principles in how we tackle this issue:

* I would like to avoid adding 'break the web' options that are easily clicked by normal users. We're trying to do the opposite in general in things like bug 851698.

* I would also like to avoid adding non-developer oriented features to the developer toolbox.

We've got the following bugs:
* bug 851698 - Add a GCLI command to help discovery of alt text for images
* bug 864249 - Add option to toggle JavaScript to Toolbox Options panel
* bug 864098 - Add "Disable Cache" to options panel

If we can make a case for why developers need extra toggles, then we can consider adding them to the options panel, but so far I don't see such a case.
(In reply to Joe Walker [:jwalker] from comment #27)
> Two principles in how we tackle this issue:
> 
> * I would like to avoid adding 'break the web' options that are easily
> clicked by normal users. We're trying to do the opposite in general in
> things like bug 851698.
> 
> * I would also like to avoid adding non-developer oriented features to the
> developer toolbox.
> 
> We've got the following bugs:
> * bug 851698 - Add a GCLI command to help discovery of alt text for images
> * bug 864249 - Add option to toggle JavaScript to Toolbox Options panel
> * bug 864098 - Add "Disable Cache" to options panel
> 
> If we can make a case for why developers need extra toggles, then we can
> consider adding them to the options panel, but so far I don't see such a
> case.

Agree but you missed 
Add option to toggle Images to Toolbox Options panel
(In reply to Marilyn Munster from comment #28)
> (In reply to Joe Walker [:jwalker] from comment #27)
> > Two principles in how we tackle this issue:
> > 
> > * I would like to avoid adding 'break the web' options that are easily
> > clicked by normal users. We're trying to do the opposite in general in
> > things like bug 851698.
> > 
> > * I would also like to avoid adding non-developer oriented features to the
> > developer toolbox.
> > 
> > We've got the following bugs:
> > * bug 851698 - Add a GCLI command to help discovery of alt text for images
> > * bug 864249 - Add option to toggle JavaScript to Toolbox Options panel
> > * bug 864098 - Add "Disable Cache" to options panel
> > 
> > If we can make a case for why developers need extra toggles, then we can
> > consider adding them to the options panel, but so far I don't see such a
> > case.
> 
> Agree but you missed 
> Add option to toggle Images to Toolbox Options panel

I don't yet have some solid logic for why we need that for all web developers. I get that it could be useful in some cases, but what part of a normal web development is enhanced by the ability to turn images off? (Assuming that we have a command to help with alt text discovery)
Any ETA??

For one
It's easy & page loading is fast
saves bandwidth(think Ldap environments)
opening loads of intranet sites which work fine w/o JS & images
plus don't hog the network resources

Agree with 28
+1


Everything is not used by everybody, but does not mean it's not a worth it
options/choices are always better

Alternatively
in customization menu we can add JS & Load images Toggle button that the user can place anywhere and use it as he/she likes?
(In reply to ElevenReds from comment #30)
> Any ETA??
> 
> For one
> It's easy & page loading is fast
> saves bandwidth(think Ldap environments)
> opening loads of intranet sites which work fine w/o JS & images
> plus don't hog the network resources

These are all reasons which normal people are interested in, and not specific to web developers. Moving the options into the web-developer section doesn't help justify them.

> Everything is not used by everybody, but does not mean it's not a worth it
> options/choices are always better

Options/choices are not always better. They can place a cognitive load on the many to benefit the few.

> Alternatively
> in customization menu we can add JS & Load images Toggle button that the
> user can place anywhere and use it as he/she likes?

Indeed, or maybe it's an add-on. But I'm not convinced that it has anything of particular use to a web developer.
(In reply to Joe Walker [:jwalker] from comment #31)

> These are all reasons which normal people are interested in, and not
> specific to web developers. Moving the options into the web-developer
> section doesn't help justify them.

But we need these option anyway & where they were they were fine but removed because It's was risky for casual users!
Like someone has said if not in webdev toolbar then a advance menu??
or anywhere else you would like these options?
> 
 
> Options/choices are not always better. They can place a cognitive load on
> the many to benefit the few.

But these are the bare necessities & it's not like these options improve the UX,
and also IMO these do not add much overhead or are changed or break everyday
as Compared to the Theme being implemented!
they stay in the code give users an options which is essential !


> > Alternatively
> > in customization menu we can add JS & Load images Toggle button that the
> > user can place anywhere and use it as he/she likes?
> 
> Indeed, or maybe it's an add-on.
whay an addon is placeing a button that complex?

>But I'm not convinced that it has anything
> of particular use to a web developer.
How come?
if a developer has to check if w/o JS & Images the layout breaks or not all they have to do is click the buttons
and they can see
IMO very easy and useful
(In reply to Joe Walker [:jwalker] from comment #31)

> These are all reasons which normal people are interested in, and not
> specific to web developers. Moving the options into the web-developer
> section doesn't help justify them.

But we need these option anyway & where they were they were fine but removed because It's was risky for casual users!
Like someone has said if not in webdev toolbar then a advance menu??
or anywhere else you would like these options?
> 
 
> Options/choices are not always better. They can place a cognitive load on
> the many to benefit the few.

But these are the bare necessities & it's not like these options improve the UX,
and also IMO these do not add much overhead or are changed or break everyday
as Compared to the Theme being implemented!
they stay in the code give users an options which is essential !


> > Alternatively
> > in customization menu we can add JS & Load images Toggle button that the
> > user can place anywhere and use it as he/she likes?
> 
> Indeed, or maybe it's an add-on.
why an addon is placing a button that complex?

>But I'm not convinced that it has anything
> of particular use to a web developer.
How come?
if a developer has to check if w/o JS & Images the layout breaks or not all they have to do is click the buttons
and they can see
IMO very easy and useful
(In reply to ElevenReds from comment #33)
> (In reply to Joe Walker [:jwalker] from comment #31)
> 
> > These are all reasons which normal people are interested in, and not
> > specific to web developers. Moving the options into the web-developer
> > section doesn't help justify them.
> 
> But we need these option anyway & where they were they were fine but removed
> because It's was risky for casual users!
> Like someone has said if not in webdev toolbar then a advance menu??
> or anywhere else you would like these options?

It's my belief that some sort of an add-on or custom build is probably the best place. For the vast majority of current Firefox users, making the web look ugly and hard to use is not a trade-off that they're willing to make to save network resources.

I agree that it is useful in some cases - but I don't think it's a good trade-off to confuse the many for those that do want the ugly-and-broken-but-fast experience.

> if a developer has to check if w/o JS & Images the layout breaks or
> not all they have to do is click the buttons and they can see IMO very easy and
> useful

bug 851698 is about a command to help with discovery of alt text for images. Perhaps when we do that we might consider adding layout change discovery, but well coded web pages shouldn't change shape when images are missing.

We've been around this block several times. If the toggle-images feature isn't useful enough for the general UI then hiding it in developer tools isn't right either. I'm going to close this bug until new information as to why developers need to turn images off comes to light.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
(In reply to Joe Walker [:jwalker] from comment #34)
> (In reply to ElevenReds from comment #33)
> > (In reply to Joe Walker [:jwalker] from comment #31)
> > 
> > > These are all reasons which normal people are interested in, and not
> > > specific to web developers. Moving the options into the web-developer
> > > section doesn't help justify them.
> > 
> > But we need these option anyway & where they were they were fine but removed
> > because It's was risky for casual users!
> > Like someone has said if not in webdev toolbar then a advance menu??
> > or anywhere else you would like these options?
> 
> It's my belief that some sort of an add-on or custom build is probably the
> best place. For the vast majority of current Firefox users, making the web
> look ugly and hard to use is not a trade-off that they're willing to make to
> save network resources.
> 
> I agree that it is useful in some cases - but I don't think it's a good
> trade-off to confuse the many for those that do want the
> ugly-and-broken-but-fast experience.
> 
> > if a developer has to check if w/o JS & Images the layout breaks or
> > not all they have to do is click the buttons and they can see IMO very easy and
> > useful
> 
> bug 851698 is about a command to help with discovery of alt text for images.
> Perhaps when we do that we might consider adding layout change discovery,
> but well coded web pages shouldn't change shape when images are missing.
> 
> We've been around this block several times. If the toggle-images feature
> isn't useful enough for the general UI then hiding it in developer tools
> isn't right either. I'm going to close this bug until new information as to
> why developers need to turn images off comes to light.

it still boggles my mind
that Mozilla will not let users decide??

why was the feature removed if it is useful??
(please stop talking rubbish about default users)


So now you guys decide what a user should do?
& how They must browse the web?

Hell even chrome/ie has these features

well
I personally gonna ditch firefox soon, I hate new bookmark star button change, I don't wanna increase my addon inventory, don't want some scriptish hacks.
I am amused to see how bad Mozilla has fallen, every FF diehard fan like me know early FF4 release days when FF started competition for FF4 possible theme and people took part in it because it was crucial for FF and Mozilla wanted to make changes what people want but now all has changed


Truth is bitter. Alas! now they will loss some crucial base of users.

I am pretty sad right now and being freedom of speech I am making my opinion, you can disagree with me completely but I will stick with my comment.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: