> Okay, let's start fresh and try this again. Long time user, 2nd post.
>
> Looking through the newsgroup, I see several people trying to
> articulate this point and explain why it's such a significant problem,
> without success on the receiving end. I don't know if I'll be more
> successful, but I'll be trying to be very concrete, logical, and step-
> by-step.
Yes! This is the best way so I can understand.
>
> Core problem description: conflation of UI visibility with activation
I do not agree with this characterization of the problem.
> I'll be trying to explain:
> 1. what this is
> 2. that this is different from previous Firebugs
> 3. why the conflation is a bad thing
> 4. why the way the change was implemented is a bad thing
>
> Scenario A:
> 1. Ctrl-F12, "Open Firebug in New Window"
> 2. See a greyed-out window with a button in the middle saying
> "Activate Firebug for the selected Firefox tab"
> 3. Think "ok, I will activate Firebug so that it will be 'on' and I
> can debug this web page"
> 4. Click the Activate button.
> 5. Discover that a page refresh is needed, and refresh the web page.
> 6. Use Firebug to investigate an issue in the web page
> 7. Be finished with Firebug for the moment, but want to continue
> working with the web page
> 8. Use i) Ctrl-W, ii) File->Close, iii) the red "X", or iv) "Open
> Firebug in New Window" to close the Firebug window.
8i, 8ii, and 8iii if you mean the red X on the Firefox tab all mean
the same to Firebug: the user is done with this web page. According to
the design, Firebug will open the next time you visit this page. As I
understand it this is the same as 1.3.
I don't understand 8iv.
> 9. User now thinks Firebug window is closed, but that Firebug is still
> running (like all previous versions) on this web page.
I don't understand why: you closed the Firefox tab that you where
debugging, how can it still be running?
> 10. Repeat step 1.
> Expected: To be in the same state as the beginning of step 8
> Actual: The user is at state 5
> Expected: That the console log and net tab have been operating between
> steps 9 and 10
> Actual: Firebug has been "suspended" during that time, so any issues
> have to be recreated
According to what I read, the web page should have been closed?
>
> Scenario A illustrates how two functions which were heretofore
> distinct:
> 1. The "on-ness" or activation of Firebug
> 2. The visibility of the user interface of Firebug
> have been merged, or conflated, into one single thing, where "thing"
> means both representation in the Firebug interface and action taken by
> the user. This conflation leads to these perceived problems:
But there is no such conflation: just hit the minimize button [_] to
see Firebug active and not showing.
>
> Expected: Hiding the Firebug UI does not turn it off for my web page
> Actual: Hiding the Firebug UI turned off console logging, script
> breakpoints, net logging
This will be fixed by changing [X] to "Off"
> Expected: I turned Firebug on for this site, it should always be
> running
> Actual: Firebug gets turned off unintentionally - the user meant to
> *hide* Firebug, but they also *deactivated* it because those two
> actions are conflated.
As I said it is not true. What is confusing is that [X] does do both
while it did not do that in 1.3.
> Expected: There is a way to have Firebug hidden but running, like all
> previous versions
> Actual: There is NO way to close the Firebug external window without
> deactivating Firebug for that web page.
That is correct. I don't plan to fix this, but I agree it is a
design flaw.
>
> These are all different ways of attempting to express the effect of
> this conflation. Now, do I need to explain how this is different from
> previous Firebug versions? In previous versions, once I got things
> turned on for my whitelist of sites (which, for me personally is just
> "localhost" most of the time), I never had to worry about it again. I
> don't think there *was* any "suspension" of Firebug previously.
Sorry you missed it.
>
> The existence of a suspension/deactivation feature is not itself a bad
> thing. However, by tying it inextricably to the visibility of the
> Firebug UI, users are forced to do both things when they only want to
> do one.
>
> The way this change was made really brought about confusion, by *not
> changing anything visible*. The menu still says "Open Firebug", not
> "Activate Firebug". The Firebug File menu still says "Close", not
> "Deactivate". This is guaranteed to confuse all the users who are
> migrating to Firefox 3.5 and are trying to deduce why/how Firebug
> changed its behavior. (The no-auto-refresh change, while a good
> change once a toggle/preference gets implemented, is another
> confounding variable to figure out.)
>
> Here are a few more problems with external window mode that are
> inconsistencies with even the new conflated model: (These are NOT the
> main issue here, they serve just to further illustrate how the
> semantics of UI visibility are subtly different for in-page mode and
> external window mode, further illustrating how the central conflation
> fails to work usefully and understandably.)
> Expected: "minimize" works the same for all modes of Firebug
> Actual: in-page Firebug is hidden completely by minimize, while the
> external window stays around in the Windows taskbar.
Well they both make the UI out of your way. I don't see why it is a
problem.
> Expected: if the Firebug UI insists on being visible when active and
> hidden when deactivated, then the external window should hide itself
> for non-active tabs
But the premise is not true.
> Actual: the Firebug external window remains open (but greyed out) when
> the user switches to a non-active tab
> Expected: external window mode v. in-page mode will be remembered
> Actual: if a user uses the "switch to non-active page, then close
> external window, then come back to active page" trick, the Firebug UI
> comes back inside the page rather than as an external window
Also a design problem I know about and one I don't expect to fix soon.
>
> I develop a web application that has server-rendered components that
> are sensitive to page size. Having Firebug pop up inside the browser
> makes my page size smaller, which causes Bad Things (tm) to happen
> with respect to debugging ability. This is why I always use the
> external window mode of Firebug, and thus why the conflation of UI
> visibility with activation hits me - and all external-mode Firebug
> users - even harder than most.
>
> Are we now close to clear on the nature of this problem?
> Again, love the tool and am here because I care. Thanks. -James
Thanks for your information, very helpful,
jjb