Closed Bug 649144 Opened 13 years ago Closed 10 years ago

Arrowpanels and Web content

Categories

(Core :: Widget, defect)

Product:
Core
Component:
Widget
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: faaborg, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

Example of web content in an arrowpanel (F1, currently targeted for Firefox 6)
59.62 KB, image/png
Details 
Last week I saw a number of demos where Web content was being displayed in an iframe inside of an arrowpanel.  These included F1, some demos from the Web apps team, and some discussion of distributed identity providers.  With so many people actively putting Web content into arrowpanels, I wanted to get a bug started to discuss the various things we need to fix.  The documentation on arrowpanels currently states:

>Note that placing an iframe, browser or editor inside a panel is not currently
>supported. Some features may work but only on some platforms. It is best to
>avoid child frames in a panel if possible.

I don't have a full sense of all of the reasons web content isn't supported yet though.

A few things that come to mind:

-we need to have a transparent background on the web content.  For instance the blank panels on OS X should have a seamless surface.
-We need to style buttons correctly for use in arrow panels.  For instance using the black buttons on OS X, instead of aqua buttons.
-we need to make sure we have full accessibility support, for both input (keyboard access) and output (screen readers, high contrast mode).
-(process point) for Firefox we need to have these interfaces go through UI review, even though they aren't really being checked in and landing in the code base

I would imagine that Dao, Neil and Gavin might have a few other considerations that we need to take into account.  I'm trying to cc everyone current working on a Web content arrowpanel so that we can discuss.
FWIW, I want to note that, regardless of whether web content should or shouldn't be supported for panels in the future, it's a bit surprising that our own developers aren't following our own documentation on this. :|

See the big red box on this page:
https://developer.mozilla.org/en/XUL/panel
URL: https://developer.mozilla.org/en/XUL/...
The specific issues are described in bug 385609 and https://wiki.mozilla.org/XUL:Panel_Improvements
As discussed in person, it's not clear to me why this stuff needs iframes past the prototyping stage, rather than a proper UI possibly fed by remote data.
(In reply to comment #4)
> As discussed in person, it's not clear to me why this stuff needs iframes past
> the prototyping stage, rather than a proper UI possibly fed by remote data.

FWIW, I second Dão's comment.

(In reply to comment #0)
> -we need to have a transparent background on the web content.  For instance the
> blank panels on OS X should have a seamless surface.
> -We need to style buttons correctly for use in arrow panels.  For instance
> using the black buttons on OS X, instead of aqua buttons.
> -we need to make sure we have full accessibility support, for both input
> (keyboard access) and output (screen readers, high contrast mode).
> -(process point) for Firefox we need to have these interfaces go through UI
> review, even though they aren't really being checked in and landing in the code
> base

These are all reasons for using proper UI.
For one, styles cannot be applied across iframe boundaries.
> I would imagine that Dao, Neil and Gavin might have a few other considerations
> that we need to take into account.  I'm trying to cc everyone current working
> on a Web content arrowpanel so that we can discuss.
Er, ignore that accidental, superfluous re-quoted paragraph.
Some context for F1/share, I work on the web UI for F1:

We want to me sharing on the web in general more humane and safe: ideally web sites should not have to litter sharing icons for different sites on all their web pages, and users should not, for example, have to give the Huffington Post OAuth access to twitter for their account, which includes the ability to read the user's account and post tweets at any time.

So part of the Sharing work we are looking at is a JavaScript API that allows web sites to invoke F1. Since web sites are very unlikely to support a share service that only works in one browser, we constructed the UI so that it could work in other browsers, via a web interface. It can be shown in other browsers either by an in-content iframe or more likely by popping a window to the F1 site.

Having the UI as web content code means that it can be updated more frequently without needing the user to explicitly upgrade their browser, and it helps avoid duplicating effort and a bunch of code in chrome and web space.

Some context on web UIs integrated with Firefox:

More features will show up in this form: a web UI that can be integrated well with Firefox. It allows Mozilla to provide useful features for users and meet Mozilla's larger goal of improving the web because it can reach other browsers, and devices that lock down native code installs, like iOS and Chrome OS.

Maybe these kinds of UIs should not be specifically in XUL panels, but some mechanism to allow them should be established. If any of you have ideas on how to do that with the existing Firefox capabilities, feel free to give us a clue, but forcing a duplication of effort/code by converting it to chrome/XUL does not seem like a useful long term solution.

I am willing to help make test cases for "browser element in a panel", just give me pointers to what is needed. If there are other things I can do given my web, non-XUL experience, like trying out new capabilities to meet this general goal, please let me know.
(In reply to comment #2)
> FWIW, I want to note that, regardless of whether web content should or
> shouldn't be supported for panels in the future, it's a bit surprising that our
> own developers aren't following our own documentation on this. :|

I can only speculate, but I suspect because it works for the most part now (it used to not work at all IIRC) so nobody was ever prompted to look up that MDC page. To be honest, I remember (possibly wrongly) that the whole goal of bug 130078 and related bugs was to make this sort of thing possible and I sort of assumed this was no longer an issue. I guess I was wrong.

We could bikeshed about whether or not it's a good idea to pull in Firefox UI from the web or not, but I don't think that's really the point here. The point is that we're going to have an increasingly number of use cases for content browsers embedded into XUL panels and unless we actually ASSERT, throw an exception or do some other super obvious thing, people are going to build UIs with iframes in panels over and over again.
(In reply to comment #8)
> To be honest, I remember (possibly wrongly) that the whole goal of bug
> 130078 and related bugs was to make this sort of thing possible and I sort of
> assumed this was no longer an issue. I guess I was wrong.

AIUI, what fixing bug 130078 made possible was overlaying chrome on top of content <browser>s or <iframe>s, like we do for the link status overlay and tab-modal prompts. Panels are a whole other issue.

> The point
> is that we're going to have an increasingly number of use cases for content
> browsers embedded into XUL panels and unless we actually ASSERT, throw an
> exception or do some other super obvious thing, people are going to build UIs
> with iframes in panels over and over again.

Good point. We should consider doing that.
(In reply to comment #9)
> AIUI, what fixing bug 130078 made possible was overlaying chrome on top of
> content <browser>s or <iframe>s, like we do for the link status overlay and
> tab-modal prompts. Panels are a whole other issue.

Yes, I think you're right.

> > The point
> > is that we're going to have an increasingly number of use cases for content
> > browsers embedded into XUL panels and unless we actually ASSERT, throw an
> > exception or do some other super obvious thing, people are going to build UIs
> > with iframes in panels over and over again.
> 
> Good point. We should consider doing that.

Or, you know, maybe make browsers in panels work... ;)
It is my belief that the restriction on content browsers in XUL panels is now fixed, as of the closing of bug 130078 -- this was a critical issue for Jetpack, and numerous fixes were made in late 2010.  The only issue that I am aware of is a bad interaction between native SELECT widgets and the view hierarchy, and fixes are on the way for that.

I believe that we can probably table the issue of whether content in a panel is technically safe and proceed with a discussion of whether it gives us the UX and data security properties we want.

Parenthetically, this probably means that the XUL panel docs are now somewhat incorrect.
I put Bug 642929 as a dependency on this bug, since it seems to be related just to web content in a panel with certain Linux drivers/graphics cards.
Depends on: 642929
(In reply to comment #11)
> It is my belief that the restriction on content browsers in XUL panels is now
> fixed, as of the closing of bug 130078

That's incorrect. See Frank's comment 9.
Myk, isn't the addon sdk using iframes inside of arrow panels for the panel implementation?
(In reply to comment #9)
> AIUI, what fixing bug 130078 made possible was overlaying chrome on top of
> content <browser>s or <iframe>s, like we do for the link status overlay and
> tab-modal prompts. Panels are a whole other issue.

Bug 130078 did indeed make it possible to place chrome above content, but, as I noted in bug 130078, comment 74, it was also a blocker for content in panels, because it caused that content to be unresponsive to user interaction.

roc implemented a partial workaround for that problem in bug 532569, but the real fix remained the one for bug 130078.


(In reply to comment #11)
> The only issue that I am
> aware of is a bad interaction between native SELECT widgets and the view
> hierarchy, and fixes are on the way for that.
...
> Parenthetically, this probably means that the XUL panel docs are now somewhat
> incorrect.

Yes, you're right, those docs are now incorrect, as content in panels now works just fine, modulo remaining bugs like bug 638430 and possibly bug 642929.


(In reply to comment #14)
> Myk, isn't the addon sdk using iframes inside of arrow panels for the panel
> implementation?

Yes, you're right, the Add-on SDK's Panel API implements addon panels as XUL panels with embedded content iframes, so addons can implement their panels using common web technologies like HTML, JavaScript, and CSS (i.e. no XUL) and don't have unnecessary chrome privileges.
(In reply to comment #15)
> as I noted in bug 130078, comment 74

Erm, I meant bug 130078, comment 94.
Adding Bug 638430 as a dependency on this bug, as we saw the select box on linux not work in web content in a panel that caused us to do our own DHTML select widget in F1.
Depends on: 638430
Not sure this bug is useful anymore.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: