Discussion of support for Modal windows within Firefox 2.0
kerc...@gmail.com
I would like to bring up a fairly serious issue with the Firefox 2.0
release - Support for modal windows.
One of the most classic methods for enabling users of a windows based
system (like X-Windows, MAC, MS Windows, etc.) to understand the
context in which they are working has been to create a popup dialog
that is modal to the opening window. These modal dialogs are often
nested and can be seen in depth and are exceptionally good for UI
reuse and tunneling. Applications which support multiple environments
have used this technique to simplify configuration and current user
context as long as there have been windowing development environments.
This interaction style is extremely useful, well understood and quite
prevalent.
As of 6 months ago, every serious programming platform (including
browser clients such as FF 1.x+ and IE 4.x+) supported modal (or
nearly modal) windows.
With the release of Firefox 2.0 we have lost all modal and popup
window control (including window z-order control, window dependency
control and cross window event control). Based on a small bugzilla
analysis
https://bugzilla.mozilla.org/show_bug.cgi?id=354123
https://bugzilla.mozilla.org/show_bug.cgi?id=180048
https://bugzilla.mozilla.org/show_bug.cgi?id=197351
https://bugzilla.mozilla.org/show_bug.cgi?id=292598
it appears that this was done to prevent the use of popup windows in
offensive ways. While I understand and applaud the concern that went
into the decision to prevent this behavior, the particular
implementation decisions taken were just plain WRONG.
One of the themes that comes up with modal windows is the statement
and presumption that the browser and all windows that are a part of
the browser belong exclusively to the user on the client machine. As
a philosophical point, this is probably accurate, but as a practical
matter, it is dubious for both historical and user interaction
reasons. Popup blocking is standard behavior for all browsers now and
well understood. Simply asking users about allowing modal windows is
MORE than sufficient to correct problems in poorly behaved sites.
Several workarounds have been proposed to this issue. Here are a few
I have researched and attempted with varying degrees of success.
1) Create an extension to overload a javascript class that opens a
modal dialog in chrome code. This actually works to some extent, but
severely limits the inter window communication (parent and child
follows
are particularly annoying here).
2) Sign your pages and request permissions from the user. This one is
probably the most frequently recommended solution and also the least
useful. Note that the problem is not obtaining a certificate and
asking for permission (which itself is a problem for some customers),
but the fact that creation of a signed jar containing all content is
simply not possible for dynamically created content. Guess who
needs the modal dialogs the most? The complex and dynamically created
web applications being deployed publicly and in intranets.
3) Utilize local div elements to cover the primary page and create
javascript dialogs. This solution can work very well for single and
small dialogs and for contexts which are very shallow, but is not
tenable for larger systems and multiple levels of dialogs. Each new
dialog must fit within the real estate of the last dialog and you lose
resizability and standard chrome. An additional issue here is that
without the use of iframes you are unable to break the name space to
prevent reuse of variables and context variables within shared
javascript modules (not everything is using javascript class
methodology.
4) Change the user interaction to use a single page with alternative
context (such as bread crumbs or similar). This COULD be done,
particular for simple applications but large teams with systems with
years of development effort simply can not change this in reasonable
time frames and are likely to simply ignore firefox rather than make
the significant investment to do this. Most of the interactions that
will work with single windows are very low in contextual content and
unlikely to be implemented for complex configuration withing DHTML
implementations.
I would like to recommend a solution that may be gather some flames...
"Implement the non W3C DOM compliant function showModalDialog() and
showModelessDialog() currently found in IE."
Why?
- The firefox browser would instantly be able to use 'standard' code
written for IE that has been well and thoroughly tested for nearly 10
years.
- Firefox has implemented similar non-compliant behaviors for
compatibility reasons in the past (innerHTML comes to mind).
- Developers can rapidly convert to this method and understand it
well.
Additionally, the popup blocking logic should be extended to
explicitly query for z-order and modal dialog control to ensure that
poorly behaved sites are prevented from causing problems of this type.
As Firefox 2.0 now stands, public facing applications and a large
block of high end web applications can not support it completely. In
particular, banking systems, financial systems, reservation systems
and complex web applications may need to explicitly PREVENT the use of
Firefox 2.0 to ensure correct behavior of their applications in
deployed environments. Firefox does not have the usage percentage to
force interaction design changes in these environments... it is a
battle the Mozilla Firefox team will LOSE... and that would be a
shame.
I would really like to hear some response to this from the Mozilla
team. This problem won't go away just because you want to ignore it.
I suspect you are already seeing this just from other posting and
bugzilla activity.
Thanks for any feedback and responses (in advance).
jbk
Gijs Kruitbosch ("Hannibal")
> <snip>long story</snip>
If this were a bug, it would be marked a DUPE of
http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/ca16846db5bb2b5
Please search before posting that long a list of advocacy, as what
you're saying has mostly been discussed already anyway.
-- Gijs
(Not affiliated with MoCo/Fo, so best not consider this your "response
from the Mozilla team")
kerc...@gmail.com
> http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/ca16846db5bb2b5
>
> Please search before posting that long a list of advocacy, as what
> you're saying has mostly been discussed already anyway.
Gijs, I would like to thank you for bringing that topic to attention in
this thread. That thread is not quite a duplicate, but is highly
related. I do hope that my post above imparts some motivation and
discussion that is more then a simple rehash of that thread. I also
hope that the development team for Firefox is not disposed to dismiss
this discussion thread as a DUPE quite as quickly as your first
response here implies...
The referenced thread does discuss a couple of the work arounds
mentioned above and advocates a simple rollback to prior behavior.
Restoration of the prior behavior would solve the problem to some
extent, but would propagate the difference in behaviors that existed 6
months ago and still would not allow true and simple modal behaviors
that IE has had for the past decade.
I am not the first to be dismayed by the changes described above and I
will not be the last. I have not been able to find any reasoned
discussions elsewhere that involved the decision makers within the
firefox product and would love to have those discussions or links to
those discussions posted here.
jbk
Jesper Kristensen
will force some websites to work nicely inside its box, and i hope it will
bring down some of the annoyances I see, when webapps use popup windows. Now
i think the next step would be to completely deny access to window.open,
window.alert, window.prompt, window.confirm and likely methods from the web,
but unfortunately i don't think it will happen any time soon.
--
Jesper Kristensen
kerc...@gmail.com
Jesper Kristensen wrote:
> will force some websites to work nicely inside its box, and i hope it will
> bring down some of the annoyances I see, when webapps use popup windows. Now
Unfortunately, there are two main classes of web based applications.
Those intended for large audience consumption (Google, NetFlix, etc)
that are information and presentation based and those intended for
significantly more complex tasks (and more limited customer
demographics) like charting, finance, media and information authoring,
and so on.
The simple applications really don't need much configuration and are
not trying to maintain a complex and dynamic visual context for
customers (but note that even Amazon/Netflix/etc. struggle to deal with
the limitations that the wide browser support they need imposes).
Since application front ends are moving to thin client models (using
browsers), the capabilities of the browsers must keep pace with the
very reasonable needs of the more complex applications. This is just a
very simple and clear requirement. Additionally, it is a requirement
that is already met with IE. As more and more customers request thin
client access to their large applications, this requirement will just
gain in importance over time.
Prognostication: Popup dialog usage will NEVER go away.
The browsers either must support popup dialog control or those browsers
will not be supported by the large enterprise and IT community.
Be very clear, without that community behind you, extended penetration
into the browser market will not occur.
The question does remain as to how you enable the general public to
limit the annoyances found surrounding this issue, but the solution of
removing support for control of dialogs just is not going to work.
jbk
ma...@meteli.net
dialog solution using nested IFRAMES and though it works ok, it still
feels like a hack in many respects.
I think an excellent temporary solution would be to implement this as
an add-on. Actually I am quit sure somebody has done this, do anyone
here now about one??
Some properties of the Internet Explorer solution, like script
execution stopping in the main winow could be quite difficult to
implement but for me even a less compatible solution would be
acceptable.
If there is no such add-on I _might_ be willing to produce / help
develop one, especially if there is some interest in helping /
sponsoring the development.
macke