Bug 206426 - templates: Use "view" rather than "edit" links in attachment emails
Summary: templates: Use "view" rather than "edit" links in attachment emails
Status: Open
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Only Me
Assignee: Bugmeister
Keywords: needs-qa
Depends on: 225060 204374
  Show dependency treegraph
Reported: 2016-01-20 11:40 UTC by Andriy Gapon
Modified: 2022-10-28 03:27 UTC (History)
3 users (show)

See Also:

Screenshot of edit view rendering attachment (109.50 KB, image/png)
2016-01-20 12:56 UTC, Mahdi Mokhtari
no flags Details
attachment edit view (91.46 KB, image/png)
2016-01-20 14:16 UTC, Andriy Gapon
no flags Details
mixed content blocking (firefox 44 beta) (16.97 KB, image/png)
2016-01-20 14:20 UTC, Kubilay Kocak
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Gapon freebsd_committer 2016-01-20 11:40:27 UTC
The link does not seem to be convenient for actually seeing the attachment.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-20 12:54:41 UTC

The 'edit' view contains an area for attachments who's mime types are renderable in a browser to be displayed.

The attachment mentioned is set to text/plain, and it renders correctly in the browser, at that URL, correctly.

My guess is that this issue is related to 'mixed content' between the main Bugzilla (https), and the attachments host (http).

My browser (Firefox 440b9 Beta) blocks this mixed content by default, and I believe a number of other browsers do, but other browsers do not. 

We'll have to solve this properly in the long term, but in the short term, bugzilla 'is' working as expected, correctly, that is; attachments that can be displayed, are displayed in the 'edit' view.
Comment 2 Mahdi Mokhtari freebsd_committer freebsd_triage 2016-01-20 12:56:26 UTC
Created attachment 165864 [details]
Screenshot of edit view rendering attachment
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-20 12:58:08 UTC
@Andriy, can you confirm whether it's the browser blocking mix-content that's causing the attachment not to be displayed?
Comment 4 Andriy Gapon freebsd_committer 2016-01-20 14:15:01 UTC
(In reply to Kubilay Kocak from comment #3)
That sounds plausible although I am not sure how to confirm that.
I'll attach a screenshot of what I am seeing.

OTOH, I am still not convinced that the notification emails should contain the edit link.  How likely is it that a person watching a bug would like to edit someone else's attachment?  As opposed to just taking a look at it.
Comment 5 Andriy Gapon freebsd_committer 2016-01-20 14:16:46 UTC
Created attachment 165867 [details]
attachment edit view

This is how I see the attachment editing page accessed via a link in a bugzilla-generated email.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-20 14:18:30 UTC
(In reply to Andriy Gapon from comment #4)

I know and understand what you mean by edit not seeming like the right thing to do. I'll leave that as an open consideration for improvement. Having said that 'edit' in this context is unfortunately a terrible name for the view :)
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-20 14:20:07 UTC
Created attachment 165868 [details]
mixed content blocking (firefox 44 beta)

My browser wasn't showing things in the preview pane either for the example bug referenced. I confirmed viewing worked fine when disabling the mixed content blocking.

Attached is what I saw
Comment 8 Andriy Gapon freebsd_committer 2016-01-20 14:20:55 UTC
Yes, I see now the icon telling that "Firefox blocked parts of this page that are not secure".
Comment 9 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-23 19:37:07 UTC
This is partially resolved by bug 204374 (making attachment viewing actually work by resolving mix-content warnings), but this issue will remain open to consider updating email templates to use URL's pointing to view attachment, not the edit view.