we've got one more issue that I think is important for 1.4. Objects showing as Undefined in the DOM panel. This seems to be a regression occurring between Firebug 1.4.0a31/b1 and b2.
Still don't have an issue on file for it. Also, your blog post is a little misleading as we agreed last week that we'd wait for Honza to come back before releasing 1.4.0 final. I still think we should hold off until his return and we have a fix for the DOM issue. I'll try to post the issue with a testcase today if I can't find a match in the database. On Jul 6, 11:48 am, johnjbarton <[email protected]> wrote: > James, thank you for responding to my request for more information. I > am hoping you or others will not be put off my by response. The reason > is that I am not able to use this kind of information. You are > describing a solution you prefer but I want to understand the problem. > I've added more comments below, not in an effort to dissect your reply > but rather to try to make my request for information about the problem > clearer. > > On Jul 5, 11:26 pm, nod <[email protected]> wrote: > > > "Some users are confused by or object to the use of the [X] icon. > > Resolution: issues are still unclear to me." > > > I view the fundamental problem here as the *conflation of the display > > UI with the whitelist*. In addition to all that's been written here, > > I'll add that it severely hampers the usage of Firebug in external- > > window mode. > > Please illustrate the problem you have with Firebug in the external > window. What I need is a sequence of UI operations or observations > that fail to work. It maybe that the solution for the problem is to > add some feature like the one you request, but until I understand the > problem I cannot act. > > > > > Firebug 1.3 (and earlier) behavior clearly and cleanly established > > that Firebug acted like a background process with a hide-able UI > > display, similar to instant messenger clients. I believe the solution > > However Firebug is not a background process. Nevertheless my question > here is about 1.4, not about 1.3. What about the way 1.4 acts is a > problem? > > > for 1.5 or asap is to simply *give the whitelist a separate > > affordance* and restore the effect-free display/hide of the UI. If > > The phrase "effect-free display/hide" sounds like minimize to me. What > about the minimize feature in 1.4 does not work for you? > > > Firebug remains committed to the UI == whitelist concept, I could file > > a couple bugs on the whitelist v. external window troubles - but I'd > > much rather have the root issue improved. > > I strongly urge you to act because the I have no plans for further > work on activation outside of fixing bugs. > > > > > First time poster, love the product and use it every day, here giving > > feedback because this is a big deal. "What the *** was wrong with it > > before?" a co-worker opined as we tried together to figure out what > > was going on with 1.4. > > I am in the middle between folks of differing opinions. But that does > not matter now because our option here is the figure out what we can > do to make 1.4 successful. > > > > > To sum: > > Problem: addition of whitelist/blacklist effect to display/hide of UI, > > which had formerly been effect-free > > I guess there is some mis-understanding about the display/hide > function in 1.3. > > > Solution: add separate affordance for whitelist/blacklist, > > disentangling that function from the UI's visibility > > Again though, I am looking for the problem, not a solution. > > Thanks! > jjb --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/firebug?hl=en -~----------~----~----~----~------~----~------~--~---
