1427439 - No Link to Logoff

Status: RESOLVED DUPLICATE of bug 1426673

(Bugzilla :: User Interface, defect)

Description

[David E. Ross]

I cannot find a link to logoff from a session of bugzilla.mozilla.org.  This was previously reported in bug #1426673.  However, a side issue about unrelated software confounded the discussion there, resulting in that bug being closed.  

This is a security issue.  Users cannot terminate their secure logon without completely terminating all instances of their browser session.

Comment 1

[David E. Ross]

It appears that the problem is caused by having the image for the Account menu supplied by a third-party Web site.  My browser preferences are set to load only images from the originating server, effectively blocking images from third-party servers.  Note that, if that third-party server goes down or if for some reason it cannot be reached, users cannot logoff from bugzilla.mozilla.org.  Indeed, users cannot then access any part of the Account menu.

Comment 2

[Gérard Talbot]

> My browser preferences are set to load only images from the originating server, effectively 
> blocking images from third-party servers.

I am curious. How do you block images from third-party servers? Are you using a particular extension?
I am using Firefox 52.5.2 ESR and I can not find a setting or preference which would block images from third-party servers.

> if that third-party server goes down or if for some reason it cannot be reached,

I have not heard from Ghostery support people so far but I starting to guess that the gravatar.com code might be something like this: if its cookie is refused by a particular BMO user, then its gravatar image will not be fetched ... which causes the cascade effect on the account menu that we know.

Comment 3

[Dave Miller [:justdave]]

The alt tag on the image appears to be blank.  I suspect an easy fix for this would be to put an alt="Account" or somesuch on the img tag.  But that depends on the method being used to block the image.  If it's removing the <img> tag from the document you're still screwed.  If it's just actually preventing it from loading, then the alt tag should fix it.

Comment 4

[David E. Ross]

Having a blank alt tag in an img element is the same as not having any alt tag at all.  This is a violation of the W3C specification for the img element in both HTML 4.1 and HTML 5.  Mozilla has long asserted that its products are specification-compliant.  This bug, however, is caused by Bugzilla not being compliant with HTML specifications.  

My testing indicates the Account menu is present while its icon is invisible if only images from the originating server are allowed.  However, there remains the question of why Bugzilla is dependent on a third-party Web site for an icon.

Comment 5

[David E. Ross]

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #3)
> The alt tag on the image appears to be blank.  I suspect an easy fix for
> this would be to put an alt="Account" or somesuch on the img tag.  But that
> depends on the method being used to block the image.  If it's removing the
> <img> tag from the document you're still screwed.  If it's just actually
> preventing it from loading, then the alt tag should fix it.

My testing shows that the text for the alt attribute appears when the browser preference is set for either "No images" or "Images only from the requested domain".  You can test this yourself with my Web page at <http://www.rossde.com/test/remote_image.html>.

Comment 6

[Gérard Talbot]

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #3)
> The alt tag on the image appears to be blank.  I suspect an easy fix for
> this would be to put an alt="Account" or somesuch on the img tag.  But that
> depends on the method being used to block the image.  If it's removing the
> <img> tag from the document you're still screwed.  If it's just actually
> preventing it from loading, then the alt tag should fix it.

If the image was an <img> with an usemap attribute (adequately coded), then it could be possible to simulate a vertical list of 6 links of account menu which would include the Log out link.

Bug 63730 comment 26 indicates that Lynx 2.8.5, Opera 8, Seamonkey 1.5 and Minefield/3.0a4pre passed a test I did with image download blocked. An unordered list of clickable links was rendered and working despite the image not loading.

> However, there
> remains the question of why Bugzilla is dependent on a third-party Web site
> for an icon.

Agreed. Why the bugzilla software (and the display of My Profile, My Activity, Preferences, Log out links) so critically depends on 3rd party cookie and/or an image served by a 3rd party server?

Comment 7

[Dave Miller [:justdave]]

Nothing related to this bug is depending on any cookies, third party, local, or otherwise.

The image is from Gravatar, because it's an avatar image hosting service that a lot of people actually use, and it's easier to let that work than implement local avatars (that said, there's no reason we couldn't locally implement it - I'd love to see a choice between "upload one" and "use my Gravatar" in the preferences).  When using Gravatar, you create an MD5 hash of the email address and generate a link using that hash, and it gives you back an avatar image if that user has set up one there, and a generic avatar if they haven't.

You can also disable it in your preferences (if you can get to them of course, which is what this bug is trying to solve - chicken: meet egg).  There's two options related to it in the General Preferences tab.  If the "show my avatar image to other users" option is disabled, it goes away for yourself as well (including the one in the header) and is replaced by a local generic avatar image from Bugzilla.

It's inside a <button> element.  I suspect the CSS that creates that dropdown menu (which is tied to the <button> not the <img>) will work just fine with alt text that says "My&#13;Account".  In fact, it does, I just tried it.

So all we need to do to fix this is add real content to the alt attribute on the <img> element.

Comment 8

[Gérard Talbot]

https://www.w3.org/WAI/GL/WCAG20/tests/test13.html

and

https://www.w3.org/WAI/GL/WCAG20/tests/testfiles/13-2.html

is very close to what I explained.

Comment 9

[Dave Miller [:justdave]]

Attachment: patch1427439.diff

Comment 10

[Kohei Yoshino [:kohei]]

The same content blocking issue as Bug 1426673.

Comment 11

[Dylan Hardison [:dylan] (he/him)]

Also, re: the alt text, I think it's empty because the parent element already has an aria label.

Comment 12

[Dave Miller [:justdave]]

Comment on attachment 8939186 [details] [diff] [review]
patch1427439.diff

I guess if the bug is dead the patch doesn't need review :-)