Bug 77543

Created attachment 126113 [details] Screenshot with hidden navigator.

Created attachment 126114 [details] Screenshot with pinned navigator.

Created attachment 126115 [details] Screenshot with navigator overlay.

Created attachment 126122 [details] Patch

Screenshot with hidden navigator -------------------------------- +100! Screenshot with pinned navigator -------------------------------- +100! Screenshot with navigator overlay -------------------------------- Hideous beyond belief! Why would some do such a thing? :-) I'd vote for not including it, it's just more code that has to be maintained.

> Hideous beyond belief! Why would some do such a thing? :-) I'd vote for not including it, it's just more code that has to be maintained. We need a mode similar to the current file selector implementation, in which file selector is modal and closes upon selection.

This is needed both for users with small screen and for debugging with undocked inspector, that is usually not so wide.

(In reply to comment #6) > We need a mode similar to the current file selector implementation, in which file selector is modal and closes upon selection. Why does this NEED to be MODAL? I'm not familiar with the modal file selector (or even what is). What user gesture or event triggers the overlay into this mode? (In reply to comment #7) > This is needed both for users with small screen and for debugging with undocked inspector, that is usually not so wide. The "small screen" rationale I can buy. Must be a pretty small screen though. Those subpanels on the right (Watch Expressions, etc) sure look like they're taking up a lot of room. You've seen Xcode's shifting bottom panels thing before, right? Seems like a better ui paradigm to me. Besides, with Remote Web Inspector, who needs to debug on a small screen? :-) OTOH, Eclipse has a similar capability called Fast Views (which I never used). And iPad has modal pop overs (which I can't stand).

(In reply to comment #8) > (In reply to comment #6) > > We need a mode similar to the current file selector implementation, in which file selector is modal and closes upon selection. > > Why does this NEED to be MODAL? I'm not familiar with the modal file selector (or even what is). What user gesture or event triggers the overlay into this mode? We don't want to regress inspector's behavior, so our goal was to keep it as similar to the current file selector as possible. Currently it is modal, meaning once you click on combo box you can't do anything until you close it by selecting a file or clicking elsewhere. > (In reply to comment #7) > > This is needed both for users with small screen and for debugging with undocked inspector, that is usually not so wide. > > The "small screen" rationale I can buy. Must be a pretty small screen though. We have already used current implementation of navigator (it can not be hidden now) for some time and it takes too much space in undocked or side-by-side/dock-to-right modes. > Those subpanels on the right (Watch Expressions, etc) sure look like they're taking up a lot of room. You've seen Xcode's shifting bottom panels thing before, right? Seems like a better ui paradigm to me. I am not sure what do you mean here, but it feels like another feature to me. Could you please file a new bug about watch expressions layout providing some more description and screenshots? > > Besides, with Remote Web Inspector, who needs to debug on a small screen? :-) Not everybody uses Web Inspector this remotely though. > OTOH, Eclipse has a similar capability called Fast Views (which I never used). And iPad has modal pop overs (which I can't stand). This overlay was inspired by Eclipse's Fast Views indeed. I haven't used it in eclipse either because I usually open eclipse full screen on a wide monitor, while inspector is often used in small undocked window.

Comment on attachment 126122 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=126122&action=review > Source/WebCore/inspector/front-end/SidebarOverlay.js:40 > + WebInspector.DialogDelegate.call(this); Overlay is not a dialog. We should come up with a better abstraction. > Source/WebCore/inspector/front-end/SidebarOverlay.js:68 > + this._view.markAsRoot(); Why do you mark this view as root? It could have a valid element ancestor.

(In reply to comment #10) > (From update of attachment 126122 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=126122&action=review > > > Source/WebCore/inspector/front-end/SidebarOverlay.js:40 > > + WebInspector.DialogDelegate.call(this); > > Overlay is not a dialog. We should come up with a better abstraction. I'll take care of that separately, I filed https://bugs.webkit.org/show_bug.cgi?id=78229 for that. > > Source/WebCore/inspector/front-end/SidebarOverlay.js:68 > > + this._view.markAsRoot(); > > Why do you mark this view as root? It could have a valid element ancestor. In current implementation Dialog creates a glass pane that is a child of body element, so it does not have any ancestor views. Drawer also needs to call markAsRoot(). I'll have a look on that separately to see how this could be addressed.

Committed r107235: <http://trac.webkit.org/changeset/107235>