1.4 Issues Summary
0 views
Skip to first unread message
John J Barton
Jul 6, 2009, 1:16:17 AM7/6/09
to Firebug
Here are the main points I took away from discussions about 1.4:
http://blog.getfirebug.com/?p=232
If something you raised is not on this list, then I did not understand
it, could not fix it, or forgot about it. I welcome further
discussions. Things added to the issues list will remind me or be
picked up by someone else if there is a test case attached.
jjb
http://blog.getfirebug.com/?p=232
If something you raised is not on this list, then I did not understand
it, could not fix it, or forgot about it. I welcome further
discussions. Things added to the issues list will remind me or be
picked up by someone else if there is a test case attached.
jjb
nod
Jul 6, 2009, 2:26:16 AM7/6/09
to Firebug
"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.
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
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
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.
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.
To sum:
Problem: addition of whitelist/blacklist effect to display/hide of UI,
which had formerly been effect-free
Solution: add separate affordance for whitelist/blacklist,
disentangling that function from the UI's visibility
James
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.
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
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
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.
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.
To sum:
Problem: addition of whitelist/blacklist effect to display/hide of UI,
which had formerly been effect-free
Solution: add separate affordance for whitelist/blacklist,
disentangling that function from the UI's visibility
James
johnjbarton
Jul 6, 2009, 10:48:37 AM7/6/09
to Firebug
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 <james.a.ba...@gmail.com> 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
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 <james.a.ba...@gmail.com> 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.
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
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
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.
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.
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
function in 1.3.
> Solution: add separate affordance for whitelist/blacklist,
> disentangling that function from the UI's visibility
Thanks!
jjb
Rob Campbell
Jul 6, 2009, 12:14:29 PM7/6/09
to Firebug
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.
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.
johnjbarton
Jul 6, 2009, 12:45:50 PM7/6/09
to Firebug
On Jul 6, 9:14 am, Rob Campbell <robmcampb...@gmail.com> wrote:
> 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.
http://code.google.com/p/fbug/issues/detail?id=1956
http://code.google.com/p/fbug/issues/detail?id=1963
>
> 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.
http://groups.google.com/group/firebug-working-group/browse_thread/thread/28437ca42b01ed00
I agree that the DOM undefined issue needs to be fixed for 1.4.0.
jjb
Elias
Jul 6, 2009, 2:06:04 PM7/6/09
to Firebug
I am not sure if this is the right place to bring this up, but ever
since I installed 1.4b3, I noticed a choice on the context menu of
every page I visit, saying "Open With Editor". Is there any way to
remove this? I tried looking for a setting somewhere but I couldn't
find it.
Elias
since I installed 1.4b3, I noticed a choice on the context menu of
every page I visit, saying "Open With Editor". Is there any way to
remove this? I tried looking for a setting somewhere but I couldn't
find it.
Elias
Reply all
Reply to author
Forward
0 new messages