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 (bartlomie...@zend.com) 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@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/pdt-dev
_______________________________________________ pdt-dev mailing list pdt-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/pdt-dev
