Hi,
I don’t know what was a history of this view. From my perspective (I’m full stack PHP developer) this view is useless, even on CLI - text output is enough. Browser rendering without access to DOM it’s just an addon. In theory this could be usable for those who working on cli image generators.
I think we could drop browser output and move text output into standalone eclipse console (register PHP Debug Console).
--
Dawid Pakuła
+48 795 996 064
On 23 October 2015 at 19:03:39, Bartłomiej Łączkowski (bartlomiej.l@xxxxxxxx) wrote: Hi Team,
I have noticed that we have a nasty problem with "Browser Output" view
when debugging on Windows
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=480520). As Eclipse uses
IE implementation as a default on Win, it might cause a lot of problems
as IE is obviously a crap. Moving right along to the issue, "Browser
Output" view is in general used to render and present the content
returned from debugger engines. As this output is not always predictable
(e.g. image data might be sent as text/html type content or type content
is just simply not available) it sometimes tries to render some output
which is just simply a chain of chaotic characters. When this mess is
passed to SWT browser on Linux or Mac, fortunately everything is OK as
Mozilla and WebKit can handle it without a problem. But when it comes to
Win, IE just simply hangs... When IE hangs, Eclipse UI hangs too as some
SWT calls can't get response and user has to kill the IDE. After two
days of trying to find a solution/workaround I couldn't find anything
that can help to fix it.
Below you can find a few ideas that might help to reduce the annoyance
of this issue, but maybe some of you can help me to find a more
reasonable solution:
1. The debug output content that can be pre-checked to find out if it is
a valid HTMl/XML/"anything that is valid" before passing it to SWT
browser. As determining if it is a "valid" content is not straight
forward (but maybe I am wrong and you can enlight me :-), I don't think
that it is a good idea taking into account that it would require
additional parse/check etc.
2. As "Browser Output" view is forced to be opened every time when debug
session starts, we can change the default preference to not showing it.
If user would like to use it then he\she can just simply open it/change
the preference. But the problem is that many of the users have this view
already opened in PHP or Debug perspective.
3. Do we really need this view? When I started working with PDT, this
view was a little bit confusing for me as I already had the content in
internal/external browser. What's more, sometimes I wanted to interact
with the content in this view by mistake. When debugging "Web App" it
seems to be completely redundant as user already have internal or
external browser content available. The only benefit of having it (in my
opinion) is while "PHP CLI" debugging as you can see the rendered output
from CLI.
In general this view is more problematic than useful in my opinion. It
not only may hang the UI but it also affects the UI performance as every
debug output refreshes its content what in some case is time consuming
and slows down the debugging.
So... Fellowship of the PDT ring, what do you think about it?
Greetings,
Bart
_______________________________________________
pdt-dev mailing list
pdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/pdt-dev
|
