Closed Bug 1044370 Opened 10 years ago Closed 3 years ago

Dragging on a element which preventDefaults touch events moves the page as the dynamic toolbar shows/hides

Categories

(Firefox for Android Graveyard :: Toolbar, defect)

Product:
Firefox for Android Graveyard
Component:
Toolbar
Version:
31 Branch
Platform:
Other
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: otto, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

Screenshots of mobile Safari on iOS8 showing minified mode of controls
224.08 KB, image/jpeg
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 (Beta/Release)
Build ID: 20121024073032

Steps to reproduce:

Create a canvas, install event handlers for mouse and touch events using attachEvent(), use preventDefault() in each of these handlers.


Actual results:

If the title bar is always shown (settings), all works fine. 

If the title bar is not always shown, vertical movements of a finger over the canvas scrolls the window content in order to show/hide the title bar.


Expected results:

If preventdefault() is called, vertical movements on a canvas should not scroll the window. Consider a paint application: Painting is almost impossible because the canvas moves under your finger! (Try to paint a circle with a pen on a sheet of paper while the paper moves.)

You can try it here:
http://www.janko.at/Raetsel/Arukone/014.a.htm

(The goal is to connect same numbers by non-crossing lines.)
URL: http://www.janko.at/Raetsel/Arukone/0...
OS: Windows 7 → Android
Hardware: x86_64 → Other
This is intentional, because if this were not possible then it would be possible for a malicious webpage to block the user from accessing the title bar. They could then spoof their own title bar and effectively hijack the user's session.

If you need this sort of behaviour the best approach is to use the fullscreen API [1] to request full-screen mode, in which case the title bar will be hidden until the user hits the back button.

Does that solve your problem? Closing wontfix for now, but if you have other suggestions we can reopen this.

[1] https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
I don't agree. To show/hide the title bar is a decision of the visitor of my website, not mine. My script should simply work independently of the title bar option the visitor chooses in his browser preferences. What would you say if *my* script changes *your* browser preferences?

BTW: Goolgle chrome has also an option to hide the title bar and Chroms does respect preventDefault() even in this case.

Anyway: Do you really suggest that all scripts worldwide thar use canvas and dragging *must* switch to full screen mode?! Without any need, just to work around this "feature"?!
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Please don't change bug state.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → WONTFIX
My last comment on this issue: The current implementation clearly violates your own specification:

https://developer.mozilla.org/en-US/docs/Web/API/event.preventDefault

"Calling preventDefault during any stage of event flow cancels the event, meaning that any default action normally taken by the implementation as a result of the event will not occur."

Note: "Any default action". ANY.

The implementation in all other browser I know of don't violate this specification. FF does. There is no accepatble work-around.

The only thing I can do is to warn my visitors and suggest either to turn on the title bar or to use an other browser. 

---

Do you remember the old days "best viewed with ..."? Yes, they are back again. Best viewed with any browser except FF. Are you wondering why the market share of FF is declining?
(In reply to Alkaloid from comment #2)
> BTW: Goolgle chrome has also an option to hide the title bar and Chroms does
> respect preventDefault() even in this case.

And as expected, it is very easy for a malicious website to trap a user on their page using this behavior. The user would have to kill Chrome entirely in order to escape.

(In reply to Alkaloid from comment #4)
> My last comment on this issue: The current implementation clearly violates
> your own specification:
> 
> https://developer.mozilla.org/en-US/docs/Web/API/event.preventDefault
> 
> "Calling preventDefault during any stage of event flow cancels the event,
> meaning that any default action normally taken by the implementation as a
> result of the event will not occur."
> 
> Note: "Any default action". ANY.

"default action" is a technical term defined in W3C specs [1]. Unfortunately the "default action" of different events is undefined by the spec and left to be implementation dependent. In Firefox the default action of touch events does not include showing/hiding the address bar but in Chrome apparently they defined it differently.

[1] http://www.w3.org/TR/touch-events/#list-of-touchevent-types
Also to be clear, I'm open to suggestions to resolve this issue without compromising the user's security.
Suggestions? I'm only a user, you have much more insight in FF and in Android. Maybe one of the many developers has an idea?

However, some thoughts:

1. Full-screen mode is a nice feature, but is it worth that all websites using a canvas in a similar fashion I do become unusable?

2. You can show the title bar when the user swipes in from the top and/or from the bottom. True, this gesture is recognized by the OS, but maybe FF can get informed? (Again, I'm not an Android developer!)

3. You can show the title bar without scrolling the page down. In this case only the first few pixels of the page get hidden. This is not bad because the user can scroll up if necessary. And the user is familiar with the fact that parts of the page become invisible if he scrolls up/down. And the user may be familiar with the fact that a script can scroll the page, e.g. to bring a specific element to the top of the screen. Once the title bar is visible you should not hide it again in reaction to any event which prevents the default handling. [This is to avoid the following situation: The user holds+moves down on the canvas, FF shows the title bar, the user scrolls down outside of the canvas, the user holds+moves up on the canvas. If FF would now hide the title bar: What to do with the gap previously occupied by the title bar?]

IMHO 2. would be the best solution, 3. would be acceptable, but complicated to implement.

HTH
Chris, any thoughts on the above? Some of this might apply to the rocketbar as well.
Flags: needinfo?(chrislord.net)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #8)
> Chris, any thoughts on the above? Some of this might apply to the rocketbar
> as well.

I agree with the wontfix - a page has 2 options;

1- Size the page so that it doesn't allow the title-bar to scroll off
2- Use fullscreen mode

I guess a third possible option would be mouse lock, though I don't know if that applies to touchscreen events (probably not).

The security implications of not behaving in this way have been deemed too great, so if no one has any better ideas that don't compromise on security, then this would have to be taken up with the security team.
Flags: needinfo?(chrislord.net)
Whether or not a page could use this behaviour maliciously is secondary.  The behaviour currently in Firefox is clearly violating the spec of `preventDefault()` if not explicitly then definitely in spirit.  Additionally, it neuters many of the fine technologies in Firefox that can be used to create innovative web interfaces.

And even if a page did use `e.preventDefault()` "maliciously", this is emphatically not a security issue:  It's user interface issue.  The problem is not that `preventDefault()` is inherently malicious, bad security, or a bad idea with regards to the addressbar.  The problem is that the current user interface on Firefox Android leaves the user no options for accessing the address bar if `preventDefault()` were used.

There are several solutions Firefox could take to have the correct `preventDefault()` behaviour:

(1) `preventDefault()` stops changes in addressbar state and nothing further is added.  This is the simplest solution, and it's main drawback is that if the user visits a "malicious" page then in the very worst case he might have to restart the browser -- much like he would do if he visited any sort of malicious page, anyway.

(2) Implement (1) with an additional, alternative mechanism for opening the addressbar.  The obvious solution is that tapping the Android OS statusbar would open the addressbar.  A downwards edge slide from the top of the screen is a less obvious alternative.  You could even show the bottom few pixels of the addressbar at the top of the screen when closed to make all this clearer to the user; even the smallest screens can afford a few rows of pixels.  The page also can't control events on these pixels because they're outside the page's viewport.

(3) Have a checkbox option in the Firefox settings, e.g.: [ ] Allow webpages to prevent the Awesomepage/addressbar from showing on scroll.  By having this option checked by default, users will have the correct, expected behaviour.  Security conscious users always tweak their settings anyway.

I'm certain are many more alternative solutions, but these came to mind immediately.

I was very surprised to see this `preventDefault()` behaviour in Firefox, as I have come to expect the best in terms of standards compliance and user friendliness from this open-source project.  I strongly suggest that this issue be reconsidered.  I will gladly contribute UI designs, suggestions, etc so that this issue can be correctly resolved.
Flags: needinfo?(nobody)
Flags: needinfo?(nobody)
(In reply to Max Franz from comment #11)
> The problem is that the current
> user interface on Firefox Android leaves the user no options for accessing
> the address bar if `preventDefault()` were used.

I agree that this is part of the problem for this particular issue, and that having an alternate way to display the address bar would allow us to behave differently with respect to preventDefault.
 
> (1) `preventDefault()` stops changes in addressbar state and nothing further
> is added.  This is the simplest solution, and it's main drawback is that if
> the user visits a "malicious" page then in the very worst case he might have
> to restart the browser -- much like he would do if he visited any sort of
> malicious page, anyway.

It's not clear to me what you mean here by "nothing further is added". Can you clarify? Do you mean that the addressbar becomes unusable?

> (2) Implement (1) with an additional, alternative mechanism for opening the
> addressbar.  The obvious solution is that tapping the Android OS statusbar
> would open the addressbar.  A downwards edge slide from the top of the
> screen is a less obvious alternative.  You could even show the bottom few
> pixels of the addressbar at the top of the screen when closed to make all
> this clearer to the user; even the smallest screens can afford a few rows of
> pixels.  The page also can't control events on these pixels because they're
> outside the page's viewport.

Tapping the android statusbar is not something we have access to within the Firefox app. Your suggestion to show the bottom few pixels of the addressbar seems like a reasonable approach though.

> (3) Have a checkbox option in the Firefox settings, e.g.: [ ] Allow webpages
> to prevent the Awesomepage/addressbar from showing on scroll.  By having
> this option checked by default, users will have the correct, expected
> behaviour.  Security conscious users always tweak their settings anyway.

You'd be surprised by how many users fiddle with options they don't understand (which IMO is a good thing) but then end up with browser behaviour they consider to be "broken" (bad). An option like the one you're suggestion is pretty much a non-starter, I think. Note that the settings already do have an option to lock the addressbar in place and prevent the "dynamic toolbar" slide on/off behaviour it has by default. Checking that also solves this bug, so if it's a user-toggleable setting you're looking for - there's already one!

> I was very surprised to see this `preventDefault()` behaviour in Firefox, as
> I have come to expect the best in terms of standards compliance and user
> friendliness from this open-source project.  I strongly suggest that this
> issue be reconsidered.  I will gladly contribute UI designs, suggestions,
> etc so that this issue can be correctly resolved.

Thanks for the offer. It would be great if you could clarify what you meant by (1) above. Also I would say that the "bottom few pixels" part of option (2) you suggested is the most likely approach suggested so far that we would consider viable. We'd have to run it by the UX and security teams, but if you have the time to do a quick design mockup that would be helpful.
May I remind you that you did not technically comment my proposals from 2014-07-27 08:26:58 PDT? It's really frusttrating that you ignored it.
Sorry about that.

In comment 7 you had two actual proposals (points 2 and 3). Point 2 is not easy to do from a technical standpoint because the OS doesn't expose edge gestures, and also would not be very discoverable by users. In point 3, if I understand correctly, you're suggesting that the behavior be "one-way" - that is, moving your finger down the screen (and prevent-defaulted) would show the toolbar but moving your finger up would not hide it. That seems fine. But you also say that the content should not move in such a case and the toolbar can just obscure the content. That may be fine for some scenarios and use cases but I can guarantee that if we do that somebody will show up complaining that it breaks their use case and we'll be right back where we started. So what you described (from our point of view) is not strictly better than what we have now, it just solves a different subset of the problems. That's one of the reasons we are so reluctant to spend time implementing that and are hoping somebody will suggest something better.

Thanks.
Modification of proposal 2: Don't hide the title bar completely; leave it one or two pixel(s) high and make it transparent. These pixel rows should be able to detect a swipe in.

Modificatio of proposal 3: The toolbar should be desplayed if the finger moves down the canvas (even if preventdefaulted) AND the content may move down. But as long as the finger moves on the canvas the toolbar should never hide and the the content of the page does not move up. The difference to the current behaviour is that the movement of the content is a one-time distraction. It's still annoying, but more acceptable than the current behavior. 

Thinking again I would clealy prefer proposal 2. Also it should be simplier to implement than proposal 2.
(You have a typo in your last paragraph so I'm not sure which proposal you prefer)

Your modified proposal 2 is effectively the same as Max's proposal 2 above, which i think has promise but needs to be reviewed but the UX and security teams. Your modified proposal 3 also sounds acceptable to me and would probably be easier to do. Again it would need UX and security review although i can't imagine either team having a problem with it.

Reopening bug as we have a couple of viable options to explore now.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Summary: preventDefault() Bug → Dragging on a element which preventDefaults touch events moves the page as the dynamic toolbar shows/hides
"(You have a typo in your last paragraph so I'm not sure which proposal you prefer)" -- Sorry for that, I prefer proposal 2.
Please excuse my very late response.  I have been overly busy.  I also ordered the developer Firefox OS phone, and I was hoping I would receive it in time to give a design that could work on that device as well.  Unfortunately, it looks like it hasn't even left Singapore yet.

Anyway, please see this sketch: https://dl.dropboxusercontent.com/u/5671307/ff-prop-1044370.jpg

Of note:

- The fully closed state may be unnecessary.

- The background of the addressbar area should be black to match and blend in with the top statusbar on many OSes (should hold true for Android and iOS at least).

- The icons must be thick to be understandable in the half closed state. (The plus icon may be unnecessary with the main triline menu.)

- The icons and addressbar textbox are aligned right on the bottom of the addressbar area.  This maximises use of space and allows us to show more content in the half closed state.  If the font alignment and sizing are carefully considered, it may be possible to show most or all of the x-height even in the half closed state -- thereby maximising utility for the user.  The contrast pixels would be one or two rows of pixels that contrast with the addressbar area such that the addressbar area maintains separation regardless of page content.

- The addressbar area overall must minimise the amount of whitespace used (or perhaps blackspace given the black background colour).

- By dragging the addressbar area down a medium amount in the half open state, the addressbar area is opened.  Alternatively a tap can open it.  A swipe up puts it back in the half open state.

- A farther swipe down (i.e. farther than opening) reveals the refresh icon above the addressbar textbox and triline menu icon.  By pulling down beyond a certain threshold, the page is refreshed.  This allows for an easy gesture for refresh without sacrificing valuable screenspace.

If you have any questions or comments, I would be happy to hear them.

Thank you for your time and consideration.

-Max
I don't think the current behavior of the location bar is acceptable. Read on for why I do think so:

------------------------------------------------------------------------

The browser is the viewport/runtime for sites/apps and should give power to the developers. Not respecting a preventDefault() on touch(move) breaks look and feel in this case.

My considerations on following the advice here https://bugzilla.mozilla.org/show_bug.cgi?id=1192182:

Having to move every view that implements interaction of a web page/web app involving touch(move) events into the HTML5 fullscreen API cannot be the final solution. It feels like the fullscreen API has a purpose of its own and pushing all views that to touch(move) interaction feels like abusing it:

1. Wouldn't the result of having some views doing touch(move) interaction in the fullscreen API result in quite different look&feel for the user compared to views not being presented with fullscreen API? Is fullscreen API even supported on mobile? A quick research on cross-browser consistency reveals that the fullscreen API at its current state results in a lot of overhead for achieving a consistent look&feel to the user.

2. If a developer decides to go with the fullscreen API to have a remedy for the location bar issue caused by Firefox on Android results in having to move the complete app into fullscreen API if the app should feel consistent throughout (including all the cross-browser issues that exist right now). By feeling consistent I mean having no different look and feel when the user looks at a view in the app that involves touch(move) actions, like drag and drop and looking at a view that does no special touch(move) actions.

------------------------------------------------------------------------

I did a review on how mobile browsers behave right now (those that I have access to right now):

Safari (iOS8):
* respects preventDefault on touch events
* on scrolling down changes the location bar to minified mode (see screenshot) and hides the bottom action bar
* scrolling/panning (NO swipe gesture, but leaving the finger on the screen) does not change the location bar mode
* downward swipe gesture (NOT from the edge of screen) changes location bar to full mode/shows bottom action bar
* scrolling beyond the top of the page changes location bar to full mode/shows bottom action bar
* tapping on the minified location bar changes location bar to full mode/shows bottom action bar

Chrome (iOS8):
v44.0.2403.67
* respects preventDefault on touch events
* bar is always visible

Android (Lollipop) Browser:
v1.6.28
* respects preventDefault on touch events
* on scrolling hides/shows the location bar much like Firefox on Android is doing right now

Chrome on Android:
v44.0.2403.133
* respects preventDefault on touch events
* on scrolling hides/shows the location bar much like Firefox on Android is doing right now

Firefox on Android:
v39.0
* NOT respecting preventDefault on touch events
* on scrolling hides/shows the location bar

------------------------------------------------------------------------

As you can see every browser tested respects the preventDefault()..

BUT

.. I can perfectly see why the Firefox developers feel responsible for user security and preventing malicious scripts from spoofing something or locking the user in a site/app is also an important job of the browser.

------------------------------------------------------------------------

Right now Chrome and the Android browser on Lollipop would allow malicious scripts to cause trouble for the user by spoofing something or locking the user in the page, forcing the user to quit the browser. Those browser should definitely also take action and improve on this. I will go forward and open bugs on those projects in the next days, too.

As far as UX is concerned I think a location bar that is constantly hiding/showing when the user scrolls to me also feels far from perfect but rather distracting. Sometimes you slowly scroll up and down to read a part of page or get the right part of an web-apps view and every time the location bar distracts by showing/hiding.

The best UX while getting the logical behavior (respecting preventDefault) right, having the user secure and empowered is only achieved by the implementation of the mobile safari in iOS8. If you can get your hands on a device running it, I encourage to try it out.

------------------------------------------------------------------------

PROPOSAL:

My request to the Firefox on Android-team (and to the mobile Chrome, Android browsers and every browser that does not fulfill all requirements right now)

Implement the browser controls in a way that fulfills the following conditions:
* The browser controls MUST be visible at all times.
* The browser SHOULD implement a minified location bar for the reason of giving as much pixels to the site as possible, letting the user focus on content while retaining the possibility to go to the full mode at any time and having a url that he can rely on being the true location.
* If a minified mode is available, the browser SHOULD switch between minified an full mode in a more sophisticated way similar to Safari does at the moment. This avoids distraction through browser controls when the user intention is NOT to interact with the browser controls, e.g. scrolling the page continuously.
From what I have read, actual discussion why it can not be fixed is based on fear of FF mobile developers, this option could be used to catch user in situation where the user could not be able to show up the toolbar again once it was hidden, so trapping the user on same page.

Possible proposal and easiest solution, when event.touches.length < 2 then preventDefault should be respected and dynamic toolbar should stay at same position, but as soon user touches two fingers the browser should forward the event from primary touch to the dynamic toolbar despite of prventdefault behaviour.
In such case the malicious code would not get a chance to trap the user in worse scenario sitiation and every one would be happy, since to 99% only one finger gestures are actually suffering due this FF issue with dynamic toolbar.
Any progress on this issue? Actually many users complain about, so they have to migrate to Chrome mobile that doesn't have this issue.

By the way FullScreen API brought more other issues that users did not want it as solution.
So as last proposal browser.chrome.dynamictoolbar = false to not change to Chrome..
Still do not understand, why it can not respect preventDefault for only one touched finger (and act with antispoofing when there are at least two touched fingers)
The primary interaction with a phone is via single finger touches. Any sort of super secret escape command is just that a secret. Users won't discover the escape mode.
>>>The primary interaction with a phone is via single finger touches
And what about zoom? Isn't zoom the most used two-finger gesture on phones?
I could agree with you if there would not exist such two fingers gesture like zoom.

Let's assume, the worst scenario came...
The evil guy programmed his evil page that does not allow to show toolbar 
because preventDefault (we imagine it)get's respected for one touched finger.

What will the user do in this situation if he was trapped?
1. Firstly he will try to scoll, but since preventDefault (we imagine it) respects it for one touched finger, it does not scroll.
2. Than intuitiv he will try to zoom-in as he is used to do on his phone and since the two and more finger gestures do not respect preventDefault the user go out of trap.

What is easier than this suggestion where you do not need to reinvent the wheel to make all happy, developers and common users.

Actual behaviour is not event intuitiv, when I do not expect the screen to scroll, it scrolls, and you tell me something about secret actions :-)
(In reply to juwagn from comment #27)
> >>>The primary interaction with a phone is via single finger touches
> Let's assume, the worst scenario came...
> The evil guy programmed his evil page that does not allow to show toolbar 
> because preventDefault (we imagine it)get's respected for one touched finger.

This is pretty far from the worst-case scenario and I don't think a user would try to zoom in if they couldn't show the address bar - I'm not sure how that's intuitive?

Here's the worst-case scenario that I can think of:

The evil guy programs his page to capture all touches and displays their own fake address bar when you drag down that looks identical to the real address bar. The user navigates to a new page using this fake address bar. The evil guy programs it so that certain URLs redirect to phished URLs (and possibly uses an iframe to mask the loading/display their own fake loading chrome) without the user realising.
The real address bar is still hidden, so the user can't see that the page is insecure (or the fake address bar is still showing, showing fake security information reassuring the user the page is secure). The user logs in with their private details, which are then sent to the evil guy who collects them and sells them to the evil gang that use them for various nefarious deeds (extortion, ddos'ing, identity theft, etc.)

If a page doesn't want the dynamic toolbar affecting their touch flow, they have options for this:
1- Size your page so that it doesn't have scrollable overflow. This would make the toolbar permanently visible.
2- Use the fullscreen DOM API. This would make the toolbar permanently hidden, but the user will be able to exit fullscreen mode by pressing the return key (or whatever platform-specific shortcut it happens to be).
By scenario you described with same success it may happen even by actual stage, because you are preassuming any user is an idiot and so that user could be trapped even now, even when both faked and real toolbars are visible.

>>1- Size your page so that it doesn't have scrollable overflow. This would make the toolbar permanently visible.
Unfortunally it is not possible to size it dynamically, if you have a email, I could send you showcase, why it is not possible, and you would agree that is not the solution.

>>2- Use the fullscreen DOM API. 
I got a lot of touching bugs, and would not like to reinvent the wheel only to workaround such FireFox fullscreen mode issues, and here users are really idiot to find out of full screen mode.
That is in fact very unsmart to propose them fullscreen api, since iOS Safari works perfect, Chrome Android works perfect, even Androids native browser works perfect, but not FireFox Android.
And if I would do so, I would need to teach peoples how to go out full screen, and that is not smart at all. Easier to propose them to go into settings and set toolbar usage to false..

Well, than another proposal that would solve all problems at once.. make developers community with users and FireFox team happy.
Actually hiding toolbar is noot intuitiv in usage, the proposed solutions with fullscreen api or disabling overflow is like running against the wall.. does not bring desired effect.
Only the good solution is browser.chrome.dynamictoolbar = false
But since user are preasummed to be not smart with handling this, another proposal, some special viewport setting (like by iOS) or css, or anything else, that would tell to FireFox to disable
toolbar (browser.chrome.dynamictoolbar = false) but only for this particular page..
At least here you do not need to reinvent the wheel and would cost you not so much time to add support for such per page setting.
What do you think about?
(In reply to juwagn from comment #29)
> By scenario you described with same success it may happen even by actual
> stage, because you are preassuming any user is an idiot and so that user
> could be trapped even now, even when both faked and real toolbars are
> visible.

I am making no such presumption at all. Only one toolbar would be visible in my described scenario, and it would be visually identical to the actual chrome. It would be hard to tell that this is not the real toolbar unless you were intimately familiar with how the toolbar reacts and presents itself. I'd write the example if I had the time/inclination to do so, but I'm certain it would be possible if we did exactly as you're suggesting (comment #15 could be explored though).

> >>1- Size your page so that it doesn't have scrollable overflow. This would make the toolbar permanently visible.
> Unfortunally it is not possible to size it dynamically, if you have a email,
> I could send you showcase, why it is not possible, and you would agree that
> is not the solution.

I don't believe this. Here is how you can do what I'm suggesting:

<body style="margin: 0; height: 100%; overflow: hidden">
  <div style="height: 100%; overflow: auto">
    [ Your content goes here ]
  </div>
</body>

(note, the margin: 0 is just so that the height: 100% doesn't go above the viewport height)

> >>2- Use the fullscreen DOM API. 
> I got a lot of touching bugs, and would not like to reinvent the wheel only
> to workaround such FireFox fullscreen mode issues, and here users are really
> idiot to find out of full screen mode.
> That is in fact very unsmart to propose them fullscreen api, since iOS
> Safari works perfect, Chrome Android works perfect, even Androids native
> browser works perfect, but not FireFox Android.
> And if I would do so, I would need to teach peoples how to go out full
> screen, and that is not smart at all. Easier to propose them to go into
> settings and set toolbar usage to false..

You don't need to teach people how to exit full-screen, the browser presents UI that tells the user how and allows them to deny the page fullscreen access. I also don't think it's reinventing the wheel to add, at most, one div and two style rules to your page.

> Well, than another proposal that would solve all problems at once.. make
> developers community with users and FireFox team happy.
> Actually hiding toolbar is noot intuitiv in usage, the proposed solutions
> with fullscreen api or disabling overflow is like running against the wall..
> does not bring desired effect.
> Only the good solution is browser.chrome.dynamictoolbar = false
> But since user are preasummed to be not smart with handling this, another
> proposal, some special viewport setting (like by iOS) or css, or anything
> else, that would tell to FireFox to disable
> toolbar (browser.chrome.dynamictoolbar = false) but only for this particular
> page..
> At least here you do not need to reinvent the wheel and would cost you not
> so much time to add support for such per page setting.
> What do you think about?

This isn't really my call to make - it would be up to UX and security (I don't even work on the Android browser anymore). However, I'd say it's a bit presumptuous to think that you speak for the entire web developer community, or to say that we think our users are idiots. A page-controlled setting seems superfluous, given the above, extremely simple work-around.

If you want to see this feature discussed/worked on, I'd suggest either finding someone who works on Firefox for Android UX/UI on IRC, or posting something on the appropriate mailing list.
>I don't believe this. Here is how you can do what I'm suggesting:
My actual settings
<body width="100%" height="100%" marginheight="0" marginwidth="0" spacing="0" style="width:100%;height:100%;overflow:hidden;">
  <div id="mainw" width="100%" draggable="false" height="100%" marginheight="0" marginwidth="0" spacing="0" style="width:100%;height:100%;position:absolute;left:0px;top:0px;overflow:auto;"></div>
</body>
And it was so all the time, so when you point me on it and it still does not work, I assume, i did everything correctly.

>>You don't need to teach people how to exit full-screen
Aha, well, I had to try out all physical buttons on my device to find the correct one, and you can not expect from user that he reads all messages that the your UI shows.

>This isn't really my call to make - it would be up to UX and security (I don't even work on the Android browser anymore).
Ok, I see, pointless discussion.
(In reply to juwagn from comment #31)
> >I don't believe this. Here is how you can do what I'm suggesting:
> My actual settings
> <body width="100%" height="100%" marginheight="0" marginwidth="0"
> spacing="0" style="width:100%;height:100%;overflow:hidden;">
>   <div id="mainw" width="100%" draggable="false" height="100%"
> marginheight="0" marginwidth="0" spacing="0"
> style="width:100%;height:100%;position:absolute;left:0px;top:0px;overflow:
> auto;"></div>
> </body>
> And it was so all the time, so when you point me on it and it still does not
> work, I assume, i did everything correctly.

Hmm, my bad, I'm guessing this is bug 886969, which would be fixed when bug 776030 is fixed (I believe this is being actively worked on).

That would make this issue far more annoying :(
I think you may be able to work around this by using a container div in body, so something like:

<body style="height: 100%; margin: 0">
  <div style="height: 100%; overflow: hidden">
    <div style="height: 100%; overflow: auto">
      [ Content ]
    </div>
  </div>
</body>

But assuming this works, it is rather less elegant... Also, I imagine this would all kill scrolling performance in fennec too, until bug 776030 is fixed :(
As said already, only because of one browser trying to reinvent the wheel and hope that things get better somewhen.
Last question,
who is the main person by FireFox Mobile team who has influence on decision to allow developers to disable toolbar browser.chrome.dynamictoolbar = false per page? This would eliminate all bugs at once.
Our actual discussion ends up in trying to find workarounds for toolbar issues, also trying to eliminate the consequences of disease that came with scrollable toolbar and not the disease self..
(In reply to juwagn from comment #34)
> As said already, only because of one browser trying to reinvent the wheel
> and hope that things get better somewhen.
> Last question,
> who is the main person by FireFox Mobile team who has influence on decision
> to allow developers to disable toolbar browser.chrome.dynamictoolbar = false
> per page? This would eliminate all bugs at once.
> Our actual discussion ends up in trying to find workarounds for toolbar
> issues, also trying to eliminate the consequences of disease that came with
> scrollable toolbar and not the disease self..

There's really no reinventing the wheel here. We have a dynamic toolbar, very similar to most other mobile browsers (inspired mostly by the old Android Honeycomb browser). We've chosen not to allow pages to circumvent showing it because it's a security risk. You may disagree with this, but your disagreeing, or the fact that other browsers do something very slightly different (note, we had this feature before Chrome, and Safari's version of this has changed significantly compared to the past) does not turn this into 'reinventing the wheel' or a 'disease'. Please remember you're talking to real people here, and also that this is just a piece of software.

I don't know who the main UX or security contacts are for Firefox Mobile, but you'd likely find out by either searching the wiki(.mozilla.org) or heading to #mobile on irc.mozilla.org and asking there.
>There's really no reinventing the wheel here.
Well, it is your point of view. From my point of view Android Chrome Ok, Android native OK, iOS Safari OK, BlackBerry OK, and only FireFox mobile is full KO because preventDefault is not respected.
So, I have as developer to find workarounds and reinvent the wheel for this desease brought with scrollable toolbar.

>Please remember you're talking to real people here, and also that this is just a piece of software
It is my goal to hit your mind because there went something wrong by scrollable toolbar.
I know, possibly this toolbar is your child that you invested much time.. 
but
>Chrome, and Safari's 
these browsers do not have same desease in their behaviour only FireFox Android, so it can not be that all browsers do it wrong way and only FireFox does it correctly. The reality shows opposite facts.
(In reply to juwagn from comment #36)
> >There's really no reinventing the wheel here.
> Well, it is your point of view. From my point of view Android Chrome Ok,
> Android native OK, iOS Safari OK, BlackBerry OK, and only FireFox mobile is
> full KO because preventDefault is not respected.
> So, I have as developer to find workarounds and reinvent the wheel for this
> desease brought with scrollable toolbar.

Or perhaps find the people that could help solve your issue and discuss it constructively. The fact that your work-around doesn't work is indeed a serious bug that's been on the cards for a while (bug 886969).

> >Please remember you're talking to real people here, and also that this is just a piece of software
> It is my goal to hit your mind because there went something wrong by
> scrollable toolbar.
> I know, possibly this toolbar is your child that you invested much time.. 
> but

Ah-ah, no. We have community guidelines that warn specifically against this kind of behaviour: https://www.mozilla.org/en-US/about/governance/policies/participation/ - specifically, section iii, 'Interaction Style'. Disregarding peoples' feelings and exhibiting ill manners does not get an issue seen to any more quickly.

> >Chrome, and Safari's 
> these browsers do not have same desease in their behaviour only FireFox
> Android, so it can not be that all browsers do it wrong way and only FireFox
> does it correctly. The reality shows opposite facts.

Different. Not correct or incorrect, just different.
>>Ah-ah, no. We have community guidelines that warn specifically against this kind of behaviour
Aha, well, I see, I touched you directly when calling the actual behaviour of toolbar as desease else you would not react on it so, also very suspect :-)
In my praxis as software developer I have always to count, that not all peoples are agree with new features, some find it fantastic, other one find it bad. But never I try to play stubborn bock, I give such peoples the choice either to use new feature or disable it and use the features they have already used.
Your main problem when trying to find compromise you do not give a choice. I do not understand what you are trying protect, your self or your vision of how things should be or what else. I just see, you do not give a chance to the world to decide if anyone needs it or not..


>Different. Not correct or incorrect, just different.
What is the point why this topic was started by first initiator? What did i want to achive when pointing FireFox on these issues?
Do you really believe, developers have much fun to create zebra that works differently on different browsers? Or that was the main point of discussion to eliminate the difference.
Even if you would give the chance, but unfortunally you do not.
By the way back to my proposal to respect preventDefault for only one touched finger.
I tried to think like evil guy to trap the user.

Let's assume, you respect in your imagination preventDefault for one touched finger and the evil guy has read your described scenario and wants to reuse it to cheat user
What difficulties he will have?

1. As mentioned, when the evil guy attaches event handler with preventDefault immediatelly, than that would mean, user would never hide real toolbar and evil guy can not show his faked toolbar.
Evidently it is not what he wants.

2. But let's assume the evil guy waits for the moment until user scrolls the page at least y-pixels and from that moment he begins to call preventDefault.
Than when you notice, aha, toolbar is out of visibility and user moved y-pixels where without preventDefault the program would show the toolbar, but since the program sends preventDefault which you respect because of me, than here your famous UI could show message: to show toolbar press backward button(hello from fullscreen api) or scroll down with two fingers(as example).
And than you could show setup message like: should this message be displayed next time for this page or not?!

I think, this scenario is the best solution for now. No jeopardizing for different browsers, and every one is happy..
Hello Chris,

I got one another idea that surely could eliminate our controversy.
What about following?!

1. We know, that usually preventDefault on touchmove events are not used by most pages,
so we can only assume, when user uses preventDefault, he wants to achuieve some specific result.
2. Actually the problem, when preventDefault is used, the entire screen moves together with toolbar
without firing touchmove event or report any new scrolled positoion, but in fact the real page moves on y-axis visibly.
3. Our previous discussion has revealed many potential security risks, that could hurt FireFox image.
So even proposed way to respect at least one touched finger for preventDefault was rejected.
4. But now the question, why not to make it easy for all, when you notice usage of preventDefault
on touchmove event just display complete toolbar again, and everyone is happy!!
At least it would eliminate two main issues.
A: it can NOT be reused by potential evil guys to cheat users with faked toolbar
B: it would be intuitiv behaviour to overlay the screen with toolbar instead to move this toolbar
up/down without firing mousemove events.

Is this idea worth to be implemented?

By the way, any try to disable scrolling on body, or sub div elements are gone as soon user
zoom-in the screen little bit, because as soon the page gets scrollable after zoom in it stops
to respect overflow:hidden; and toolbar moves up/down anyway.
Hello, any update on this issue?
18 months after reporting this issue I do not expect a solution anymore. In the meantime I recommend my visitors not to use FF on mobile devices at all. Not a big problem, FF market share on Android is ~0.72%, and it's still declining.
May be smart developers from FF team notice that issue some wheen when we ask often enought. :-)
Some css-javascript-viewport setting, anything that would fix that issue per page like dynamictoolbar = false. Pretty sure for smart FF developers it is easy one hour challenge to make all happy. Still wonder, why no developer takes that issue even when being reported frequently, even by googling outside of mozilla forum peoples are complaining about this issue.
Hope things get better.
There are already enough solution proposals on the table. My current favorite is to not remove the toolbar completely, but leave it at 1 pixel height. Please don't introduce new proprietary HTML headers!
For my self I do not care about final solution, only what I care, the screen should not move when preventDefault is called and user should not need to change preferences for toolbar or enter full screen mode or do any other crazy things, also most important the behaviour should be similar on all browsers.
However to add extra specific tag into viewport is not so bad idea, as example iOS9 has specific iOS only viewport tag like shrink-to-fit only for one purpose, to workaround the issues on iOS, so I do not mind to have something similar to workaround issues on FireFox related to toolbar. For my self toolbar should be always visible and not move, and viewport tag would be possibly best place to tell the browser that user does not want hidable toolbar.
Hello,

any news on the issue?
Actually I would like to ask for improvement.
The issue can be partially workarounded if surrounding main div element is set to oveflow:hidden with fixed width/height and sub div container is set to overflow:scroll.
like that
<html>
<head></head>
<body>
<div style="overflow:hidden;width:yourviewportwidth;height:yourviewportheight;position:absolute;top:0px;left:0px;">
  <div style="overflow:scroll;width:yourviewportwidth;height:yourviewportheight;position:absolute;top:0px;left:0px;">
      YOUR SCROLLABLE CONTENT
  </div>
</div>
</body>
</html>

This works fine and the issue with toolbar does not appear anymore.
But this works fine as long user did not use pinch zoom, as soon user uses pinch zoom and there is scrollable content on window element, the issue comes back and here I did not succeed to create proper workaround (even when setting body to fixed dimensions).
(What I did not try is the on the fly adjusting of div viewport bottom dimension on scroll/and resize events, theoretically that could possibly work, but pretty hard for proper computing)

Since I see, the creators of this dynamic toolbar are not willing to fix preventDefault issue, at least I would like to offer proposal to disable dynamic toolbar in case when the virtual viewport is not overflowing window. (also not mix with visual viewport) So I think, that would at least not fix but surely mitigate the issue and make more sense.
The only real workaround is to recommend my useres to use an other browser on mobile divices (which I do now for over a year and it works fine). Sorry for that. And: It's shame, Mozilla!
>>The only real workaround is to recommend my useres to use an other browser
I hope still the best that developers are smart peoples and forget their false pride and
accomodate the request.
The other positive effect I have noticed when using
<div style="overflow:hidden;">
  <div style="overflow:scroll;"></div>
</div>
I get pretty improved drawing speed. (as example Chrome is fast without it)
So it seems, FireFox engine does not use scissor etc. to lower amount of gpu/cpu computing work if displayed area overflows visible layout.
That is a pity since most developers are not aware of that.
By the way, the bug with dynamic toolbar has gone :-)
Thank you very much, who ever implemented it! After zoom it continues to respect the dimensions, not only in unzoomed mode, but in zoomed too.
Exactly what I have asked in my message from 2016-04-13
So no dynamic toolbar pain anymore! Thank you very much!!! I am really happy about!
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: