Description of problem: Attachment can't be opened in browser window, and must be saved. To add insult to injury it's going to be saved to the default place and not save-as. That converts one simple middle click to: - middle click - wait until the save file window appears - wait until the [OK] button will be clickable - click [OK] - Go to terminal - ls -ltcr ~/Downloads - copy the last file by mouse - vim [middle click] It's at least 23 mouseclicks+keystrokes which is really annoying. Is that really necessary? Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. open bug https://bugzilla.redhat.com/show_bug.cgi?id=1650348 2. middle click to the 'attachment 1509530 [details]' in comment 2 3. hope it opens in the new tab 4. be disappointed Actual results: Expected results: Additional info:
If you click on the Details link for a text/plain attachment, it says: The attachment is not viewable in your browser due to security restrictions enabled by your Red Hat Bugzilla administrator. In order to view the attachment, you first have to download it. Is this just a default config setting in BZ5? Or did we intentionally block viewing text/plain attachments in the browser?
The display feature failed after the upgrade so had to be disabled temporarily until it can be fixed. It was working on the test server, so hopefully won't take too long to resolve.
agk is correct, there is a configuration issue with the DNS entry for the second cname, which allows in browser viewing of attachments. Currently it should be acting just like BZ4 did. If it's not, then that is a bug. Aside: The attachment isn't marked as a patch, if you edit the details and mark it as a patch it will allow you to use the shiny new patch viewer. Funny looking diff file so it might be an interesting test case. https://bugzilla.redhat.com/attachment.cgi?id=1509530&action=edit
Created attachment 1513971 [details] test patch
*** Bug 1658965 has been marked as a duplicate of this bug. ***
Can someone please look at this. Not being able to see plain text attachments directly in the browser is a very annoying regression. It works with patches using the ...&action=diff URI, which is nice, but it is not usable with other plain text attachments.
Hi Jiri, we think this is going to be addressed by Bug 1657579 and then re-enabling the attachment view configuration option, but we can't be sure about that until it hit's partner Bugzilla because it's the only other place we have with the http/https crossover.
*** Bug 1659603 has been marked as a duplicate of this bug. ***
*** Bug 1669734 has been marked as a duplicate of this bug. ***
*** Bug 1673270 has been marked as a duplicate of this bug. ***
I am pretty certain that this issue is caused by "something weird" in the production set-up. I've created a bug on the beta site and added a few attachments to it, if you click on them they work as expected. Feel free to add other types of attachments to it. https://beta-bugzilla.redhat.com/show_bug.cgi?id=1570736 We thought it was caused by the firewall doing SSL termination, but it doesn't look to be correct as addressing that in Bug 1657579 did not fix it. It does appear to have changed the behavior though as enabling the feature now triggers and endless redirect when you try and view an attachment. The only two sites this happens on are partner and prod, and as I don't have access to either system I can't ssh in and poke around to see what is going on. I've added Fernando to the CC in the hopes of him being able to help us triage this on partner-bugzilla. If not then it may be possible to have beta-bugzilla moved to be behind the same firewall/proxy set-up as is being used for partner and prod, so I can do some testing on that.
Content-disposition is different [1]. In production it really forces downloading as a file. I will check what's causing it (and why it was changed, if that's the case.) 0 [10:04:11][0] β freed@freed ~ $ http --headers --pretty all https://bugzilla.redhat.com/attachment.cgi?id=1513971 HTTP/1.1 200 OK Connection: close Content-Type: text/plain; name="search_include_dependencies_5.0.patch"; charset= Content-disposition: attachment; filename="search_include_dependencies_5.0.patch" Content-length: 5215 Date: Thu, 14 Mar 2019 14:04:24 GMT Server: Apache Set-Cookie: Bugzilla_login_request_cookie=( redacted ); domain=bugzilla.redhat.com; path=/; HttpOnly; SameSite=Lax X-content-type-options: nosniff X-frame-options: SAMEORIGIN X-xss-protection: 1; mode=block 0 [10:04:24][0] β freed@freed ~ $ http --headers --pretty all https://beta-bugzilla.redhat.com/show_bug.cgi?id=1570736 HTTP/1.1 200 OK Connection: Keep-Alive Content-Encoding: gzip Content-Length: 10319 Content-Type: text/html; charset=UTF-8 Date: Thu, 14 Mar 2019 14:04:42 GMT Keep-Alive: timeout=5, max=100 Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_perl/2.0.10 Perl/v5.16.3 Set-Cookie: Bugzilla_login_request_cookie=( redacted )); domain=beta-bugzilla.redhat.com; path=/; secure; HttpOnly; SameSite=Lax Strict-Transport-Security: max-age=63072000; includeSubDomains Vary: Accept-Encoding,User-Agent X-content-type-options: nosniff X-frame-options: SAMEORIGIN X-xss-protection: 1; mode=block 0 [10:04:43][0] β freed@freed ~ $
Changing config "allow_attachment_display" does the trick of showing inline, just confirmed. Will work on the change management soon.
Its been a long time since the last update, is there a ETA yet for when this is going to be fixed in production ?
We're discussing internally what's the best approach. (Very) soon there'll be a plan as we have a better staging environment now.
As this does not require a code change in Bugzilla I'm removing the target milestone and assigning it to Fernando. I'm pretty sure this is a configuration issue and not code related, given it works fine on other instances. If it does end up requiring some code changes we can revisit this decision.
I'm not sure if ON_QA means that we should be seeing a change in this bugzilla⦠FWIW, I don't see any change.
The instance linked to is internal and is not public, this is why the comment containing the link is private. Comments not containing the link don't need to be private ... unless they contain some other sensitive information :) How your browser displays a mime type is up to your browser and how it's configured to handle them. If you tell Bugzilla to auto detect what the mime type is, then it uses the Content-Type the browser supplied when uploading the file. If your browser gets that wrong then it's going to cause issues. e.g. 'mbox' is not a text mime type and won't be treated as plain text in most browsers. This change will not be deployed to the current production/partner/stage hosts, it's in the MPaaS backlog and will be deployed when we change hosting.
(In reply to Jeff Fearn π from comment #25) > How your browser displays a mime type is up to your browser and how it's > configured to handle them. > > If you tell Bugzilla to auto detect what the mime type is, then it uses the > Content-Type the browser supplied when uploading the file. If your browser > gets that wrong then it's going to cause issues. > > e.g. 'mbox' is not a text mime type and won't be treated as plain text in > most browsers. Ok, then IIUC bugzilla enforces 'patch' type (which is some subgroup of text/plain I guess) if 'patch' option is checked. I got confused that I uploaded the same file twice and only difference was checking/not-checking 'patch' and the behavior was different. So there can be an issue with my firefox settings, which marks a patch as a 'mbox' mime type...
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.