Bug 1145227

The log viewer is a plugin which has no control over this url routing.  I'm not sure if this is a bug with the plugin infrastructure or engine routing not being aware of the existence of plugins when accessing from a new tab.

Hi, can you please attach some screenshot or screencast to explain the issue?

From BZ description I don't understand what "Open Log Viewer in new tab" means, which UI element does it involve?

I'm adding a screenshot.

This issue is about opening the Log Viewer (see screenshot, the area in the red rectangle) in a new browser tab.

In most web browsers, you can usually open a link (in this case the Log Viewer) in a new browser tab by clicking on it with your middle mouse button. If that doesn't work, you can always click on it with your right mouse button and choose "Open in a new tab", or something very similar to that.

After that, if you look at the tab you just opened, the Log Viewer will not be displayed. Instead you will see the Virtual Machines display, which is wrong.

You can compare the results, if you click on the Log Viewer with left mouse button, it displays correctly. If you open it in a new browser tab, it doesn't display at all.

The issue is that it should display no matter how you click on it.

Created attachment 941564 [details]
location of the Log Viewer

Thanks for the screenshot and explaining the issue.

In general, "Log Viewer" (or any other) main tab is integral part of WebAdmin UI and is not meant to be opened in a separate browser window.

WebAdmin UI contains two types of main tabs:
* standard tabs (like "Data Centers"), which are part of the application
* custom tabs (like "Log Viewer"), which are added through UI plugins [1]

[1] http://www.ovirt.org/Features/UIPlugins

Main tabs are clickable links with URL containing hash token that identifies the "active" UI to be displayed.

For example, "Data Centers" main tab link URL is /ovirt-engine/webadmin/WebAdmin.html#dataCenters

Presence of hash token indicates that you should not attempt to open main tabs in a separate browser window.

As you wrote, attempting to open page like WebAdmin.html#dataCenters results in loading whole WebAdmin application - this is because the UI is designed as single-page web application, relying on hash token to perform routing across different UI "places".

Can you please explain the motivation behind having main tab content opened in a separate window?

When I'm doing something, I like to open 'Events' in a new tab in my browser. I find that it's quicker and more comfortable just to switch between tabs in the browser, as opposed to clicking on the 'Events' and waiting for the content to load. My way, I have two browser tabs opened: in the first one I'm working on something, in the second one I have Events displayed and I occasionally switch there and check the messages.

The Log Viewer is the only thing that I cannot do this with, so I filled this issue.

If you don't think it should work that way, feel free to close this issue.

(In reply to Antonin Pagac from comment #6)
> When I'm doing something, I like to open 'Events' in a new tab in my
> browser. I find that it's quicker and more comfortable just to switch
> between tabs in the browser, as opposed to clicking on the 'Events' and
> waiting for the content to load. My way, I have two browser tabs opened: in
> the first one I'm working on something, in the second one I have Events
> displayed and I occasionally switch there and check the messages.

OK, now I understand the whole context :-)

Just to clarify - I hope you're aware that if you open "Events" in new browser tab, you're actually opening the entire WebAdmin UI into this new browser tab. So you're actually running two WebAdmin UI instances in parallel. (But still, this should work OK.)

Also, note that if WebAdmin UI browser tab isn't focused (active window), refresh rate in given main tab is decreased to 60 sec, so you might see slower refreshes if the browser tab isn't focused.

> 
> The Log Viewer is the only thing that I cannot do this with, so I filled
> this issue.

Now I understand, so "standard" main tabs work (WebAdmin UI switches to that tab after loading), but "Log Viewer" main tab doesn't work.

The problem here is "Log Viewer" main tab is a custom tab, contributed by UI plugin, so core application isn't aware of it, and therefore does not switch to it after loading.

> 
> If you don't think it should work that way, feel free to close this issue.

I believe this issue is still relevant and we should fix it. We should treat all main tabs the same way.

This issue is related to UI plugin infra && core UI tab infra.

low priority; effort for resolving the issue will be very high compared to the severity of this issue / the introduced improvement (the dynamic nature of the ui-plugins-main-tabs makes this very hard to resolve - what if the main-tab isn't added until ~2 minutes after the application loads?); 

so for now flagging for rhevm-future, but this will highly likely not be resolved, so may be closed later on.

I'd like to add some additional info as follow-up to Einav's comment #8.

"Log Viewer" main tab is added (by UI plugin) dynamically & asynchronously after core WebAdmin application is loaded in the browser. I forgot to mention this in my previous comment, but the asynchronous nature of dynamic main tabs (they can be added anytime via UI plugin API) makes it very hard to resolve this issue.

In other words, when WebAdmin application loads, it has no knowledge (yet) about dynamic main tabs. What we could do is if URL includes "unknown" token like WebAdmin.html#logViewer, setup timer (1s?) to wait a bit and then try to switch to dynamic main tab, assuming it is added within this time window.

The Log Viewer and (probably the whole Admin UI) was never designed for this use case and, as such, this use case is outside of scope.  Hence, this use case would be an RFE and not a  bug.  That said this is something that we have no intention of supporting.

This BZ is essentially the same as RFE submitted by Ramesh (CC'ed):

  https://bugzilla.redhat.com/show_bug.cgi?id=1168334

The core issue is treating dynamically-added main tabs the same way as statically-defined (core) main tabs, in relation to URL token navigation (switching to main tab that corresponds to given URL token).

Even though this BZ is now close, you can follow above-mentioned RFE BZ that might fix the problem described in this BZ.