Closed Bug 1186738 Opened 9 years ago Closed 9 years ago

Zoomed view opens in about: pages

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: antlam, Unassigned)

References

Details

I was using our about:downloads page and kept triggering the magnifying glass. I think it's identifying the two list items as "clustered links" but I don't think that behavior is desired.

Can we try to remedy this?
Flags: needinfo?(domivinc)
Anthony, I think this issue is a duplicate of bug 1184762. I cannot see the issue on my side using the apk available here: https://bugzilla.mozilla.org/show_bug.cgi?id=1184937#c6 (this apk has the fixes of bug 1184912, bug 1184762 and bug 1184937).
Are you using the last nightly build or the previous apk ?
Flags: needinfo?(domivinc) → needinfo?(alam)
Just nightly :)
Flags: needinfo?(alam)
Summary: Zoomed view opens in about pages → Zoomed view opens in xul about pages
These are HTML pages, not XUL... we should probably just find a way to disable this for local chrome pages.
Using the last nightly, the zoomed view is displayed only if the click is on the gray line between 2 items of the downloads list. It seems normal in this case, the click is ambiguous.

Anthony, could you test again using the last nightly?
Flags: needinfo?(alam)
Testing on the today's Nightly...

I still think this pops up too often given the mobile-first design approach we took to these pages. I think it might make sense if say, the title text and the text below were two separate links and my tap was registering both, but it seems awkward especially if we show the zoomed view over an area of no text...

I think we have a bug filed (somewhere... can't find it right now) about tuning this feature to show up less often on sites designed with responsive web design in mind and web apps. Perhaps that will solve this issue?
Flags: needinfo?(alam)
Anthony, correct, it pops up too often! I can see now the issue clicking between the icon and the text or between the text and the date.
The html used to build an item of the list is not perfect:

<div class="row">
          <!-- This is a hack so that we can crop this label in its center -->
          <xul:label class="title" crop="center" value=""/>
          <div class="date"></div>
</div>

The xul element in the middle of the other html elements could be the reason of the issue.

I'm going to trace the cluster detection process to understand where is the problem.
(In reply to Dominique Vincent [:domivinc] from comment #6)

> <div class="row">
>           <!-- This is a hack so that we can crop this label in its center
> -->
>           <xul:label class="title" crop="center" value=""/>
>           <div class="date"></div>
> </div>

OMG! Someone should file a different bug to remove that XUL. Or maybe removing the XUL *is* the fix we need here.
Bad luck! The issue is still visible without the XUL element. In fact, the problem is linked to bug 1188185. The calculation of the number of elements in a cluster is not always correct. I made a fix here [1]. 

Regarding the removal of the XUL element, we can make it in this bug. Different solutions using html elements:

A) Using a div element with a css rule set to " overflow:hidden;text-overflow: ellipsis;" should work.
But in this case, the label won't be cropped in its center. The reason to crop in the center is probably to get the end of the file name visible. The last letters of the file name give the information regarding the type of file: .pdf .html … Now, with the icon on the left, this information is not really required in the title area.

B) Another way to fix this kind of issue, is to crop at the end, and when the user select the item in the list, the cropped title is animated. The text is moved from the right to the left in order to be able to read the full title. But in our case, the element cannot be selected, the download is done on the click event. The text direction ltr/rtl will also be an issue in this solution.

C) Another option could be to crop on the right side  the file name without the extension part and add “manually” the extension part on the right of the previous element. The text direction will also be an issue here.

Solutions B) and C) are not really easy to implement, Anthony, any comment about this visible change?


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1188185#c4
Flags: needinfo?(alam)
(In reply to Dominique Vincent [:domivinc] from comment #8)

> Regarding the removal of the XUL element, we can make it in this bug.
> Different solutions using html elements:
>
> A) Using a div element with a css rule set to "
> overflow:hidden;text-overflow: ellipsis;" should work.
> But in this case, the label won't be cropped in its center. The reason to
> crop in the center is probably to get the end of the file name visible. The
> last letters of the file name give the information regarding the type of
> file: .pdf .html … Now, with the icon on the left, this information is not
> really required in the title area.
> 
> B) Another way to fix this kind of issue, is to crop at the end, and when
> the user select the item in the list, the cropped title is animated. The
> text is moved from the right to the left in order to be able to read the
> full title. But in our case, the element cannot be selected, the download is
> done on the click event. The text direction ltr/rtl will also be an issue in
> this solution.
> 
> C) Another option could be to crop on the right side  the file name without
> the extension part and add “manually” the extension part on the right of the
> previous element. The text direction will also be an issue here.
> 
> Solutions B) and C) are not really easy to implement, Anthony, any comment
> about this visible change?

I filed a separeate bug this here: https://bugzilla.mozilla.org/show_bug.cgi?id=1189068
Yeah I think this is outside the scope of this bug.
Flags: needinfo?(alam)
^ We should keep this focused on the original issue of showing up in about:logins, etc I think.
Summary: Zoomed view opens in xul about pages → Zoomed view opens in about: pages
First, if the click position is ambiguous in about:???? pages, I think that the zoomed view should be displayed to help the user. The about:???? pages are html pages like the others. 
Why do you think that click positions cannot be ambiguous in about;???? pages ?

Second, the issue reported by Anthony in the about:download page is valid. There is a bug in the calculation of the number of links in a cluster. The zoomed view is displayed when it should not. 
This calculation error is not specific to the about:download page. this bug can occur in any pages. And it will be fixed in bug 1188185 (see my comment 8). 

My proposal is the following: wait for the resolution of bug 1188185, and see if the about:download page works correctly.
(In reply to Dominique Vincent [:domivinc] from comment #12)
> First, if the click position is ambiguous in about:???? pages, I think that
> the zoomed view should be displayed to help the user. The about:???? pages
> are html pages like the others. 

fwiw, I agree - an ambiguous click is an ambiguous click no matter the source of the pages.
While I agree on the point about ambiguous clicks, I think the issue here (for these about:* pages) should really be focused on whether or not it actually _is_ an ambiguous tap/press. I also think that 2 sizable hit areas next to each other in this case doesn't really qualify as "clustered links" :\ 

What was the behaviour before? Did users feel a need for this feature on these about:* pages before? Before this "zoomed-view" feature, what would happen if the exact same tap happened on the exact same spot? Finally, does this view in these pages really help the user "click the right link"?

I just worry this features value is going to decrease if it shows up too much.

Maybe I can clear up my concerns. My issue with it showing up right now is that (as a user), I've used "this" page before without feeling a need for it. I visit a website on my phone, I click a button (as I've always done). But for some reason, now I suddenly have to press again inside a box. And this logic can be taken to other mobile-first/ responsive design websites. 

I'm not sure how this breaks down in terms of code/logic. But all I'm saying is this isn't showing up at the right time for me.

I just want to avoid adding an extra step for users suddenly because we're trying to be 'too smart'. Also, as we saw from some of our research, there are lots of connections users are making between this and text, mobile sites, and zooming. I think this current behaviour is not really in line with user expectations/sentiment. 

hope that helps!
Anthony, I think improving the algorithm for when the clustered links appear is more likely to fix your issues - that is bug 1135369. Let's wait on resolution from that before drawing conclusions.
Depends on: 1135369
Coming in late, I know. My thinking about about: pages is that about: pages *should* be designed to be touchable by default. They should not need to be zoomed (pinch or double tap). They should be as close as possible to native as we can get from a UX standpoint.

That said, why would we need the zoom view to ever appear on about: pages? Shouldn't we look at whether a <meta viewport> is defined and maybe assume that the page is "touch friendly" and disable the zoom view?
(In reply to Mark Finkle (:mfinkle) from comment #16)
> Coming in late, I know. My thinking about about: pages is that about: pages
> *should* be designed to be touchable by default. They should not need to be
> zoomed (pinch or double tap). They should be as close as possible to native
> as we can get from a UX standpoint.
> 
> That said, why would we need the zoom view to ever appear on about: pages?
> Shouldn't we look at whether a <meta viewport> is defined and maybe assume
> that the page is "touch friendly" and disable the zoom view?

I share your point of view that about:pages should be designed in order to be unambiguous (from a touch/click point of view). 
But I also share the point of view of some of my family members, let me explain this point:

The ambiguity when a user clicks on a page (html or native) comes from TWO totally different sides:
1) the design of the page
2) the users

In point 2), the users, we should care to put all the users, not only “young normal” users, but also all the users with sight problems and/or with disabilities (intellectual, physical, …), the “normal” users aged over 40 (presbyopia)...

Point 2) is the reason why, the Firefox for desktop version has the zoom available in the menu for all the pages included the about:pages. 
It’s the reason why you can find on some platforms a zoomed view on every  screen (not only the html pages but also native pages). For instance you can open a zoomed view on the iPad desktop. It’s totally useless for me because the icons on my iPad are already too large. But for some users, they open the zoomed view.

For the Mozilla developers community, another reason to keep the zoomed view in the about:pages is the following point: it’s a good warning to detect about:pages that are not correctly designed or to detect bug in the cluster detection.
In other words, if the design of the about:pages is good and the cluster detection is also good, the zoomed view should not appear very often for “normal” users. In this case there is no need to implement a new <meta viewport>.
I'm also down for not adding extra code to disable a feature in certain places where we shouldn't need to disable it if it's working as expected.
We haven't seen this on about pages for a while and for correctness sake, it's better not to have the special case so closed.

We can reopen this if it becomes a problem while riding the trains.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.