mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 08:45:54 +03:00
[GH-ISSUE #330] Firefox on Fedora 39 doesn't show any data for tabs other than HTML #219
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#219
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tmulle on GitHub (Jul 5, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/330
When I try to look at the other tabs:
RAW,HTML Source,Headers, etc. nothing is displayed when using Firefox on Fedora 39.The only tab that works is the initial
HTMLtab.When I use Chrome all the tabs work.
Firefox 127.0.2for Fedora is the version we are using.@melloware commented on GitHub (Jul 5, 2024):
Just to add some info @tmulle and I have tested a bunch of combinations Windows, Chrome, Firefox and this seems to be the one browser with an issue that we have found.
@melloware commented on GitHub (Jul 5, 2024):
After further testing it seems to be related to being embedded in the Quarkus DevUI Window:
it works if we open Mailpit in its own tab. So this might not be a Mailpit issue but a Quarkus Dev UI issue.
@melloware commented on GitHub (Jul 5, 2024):
As a note the MailPit UI is loaded like this.
@axllent commented on GitHub (Jul 5, 2024):
Hi guys. My first question would be: what do the Firefox developer tools report (errors)? That's the first place to start as it usually provides a strong clue where things are going wrong.
@tmulle commented on GitHub (Jul 5, 2024):
No errors in the Web Developer console just warnings when run in the Dev UI and no errors on the Network tab when clicking tabs.
@axllent commented on GitHub (Jul 5, 2024):
Thanks @tmulle. That's unfortunate (that there are no errors). I'm afraid I simply do not know, and I'll need to defer this back you to you guys to further debug in Quarkus as that is what is resulting in this issue on Firefox. I am completely unfamiliar with Quarkus. Once we actually know the reason, then we can investigate how to potentially fix it.
Just for reference, I am able to run Mailpit within a stand-alone html file (
<object width="100%" height="100%" type="text/html" data="http://localhost:8025"></object>) with Firefox 127.0.2 (Ubuntu) without any issue - tabs etc all work as expected, so I suspect it may have something to do with the Quarkus application itself. Those tabs in Mailpit consist of inline html (generated via Vue) or iframes, so if none of the clicked tabs are working it indicates to me that the Bootstrap tabs functionality may be conflicting with the Quarkus container (I am not overly familiar with the use and downsides of<object>vs<iframe>and whether object results is JS conflicts unlike iframe which is completely separate).Things to try:
Does Mailpit work when you access it directly (not via Quarkus) using your version of Firefox (ie: by visitingSorry, I just re-read an earlier message saying this worked.http://localhost:63347- assuming that's the right port)?RAWtab for the first time when viewing a message), does your browser do a network request tohttp://localhost:63347/api/v1/message/<id>/raw(it should as this is only loaded on demand when the RAW tab is clicked)?tab-pane(ie: the content for each tab), and when a tab is clicked the respective tab-pane should get a class ofactive.@melloware commented on GitHub (Jul 6, 2024):
Yep we think it's specifically Fedora and Firefox. Ubuntu seems to be ok. And yes the app works fine if it's opened not inside a frame
@axllent commented on GitHub (Jul 6, 2024):
Thanks for the confirmation. It sounds very, very specific, a needle in a haystack - a specific version (?) of Firefox on a specific platform, only whilst viewing Mailpit via Quarkus. I wonder if it's some Red Hat specific security patch they apply to Firefox which affects functionality within an object?
I think there is potentially still merit in testing points 2 & 3. Another good test that would be good is creating a standalone html file with just
<object width="100%" height="100%" type="text/html" data="http://localhost:63347"></object>and opening that with Firefox - ie: does that work. That would tell us if it is some restriction to<objects>(if it doesn't work), and whether is has something to do with the Quarkus UI (if it does work as expected).Either way, I don't think there is anything I can do to Mailpit to fix it as it doesn't appear to have anything to do with Mailpit itself.
@melloware commented on GitHub (Jul 6, 2024):
I agree with you. Not a Mailpit issue.
@axllent commented on GitHub (Jul 6, 2024):
Thanks @melloware. Just for the record, I installed Fedora today in a VM and tried Firefox with just a blank page with
<object width="100%" height="100%" type="text/html" data="http://localhost:8025"></object>- it worked as expected. It definitely seems related to Quarkus.I will close this issue for now, but please feel free to reopen or comment if the problem has been identified, and if it is something relating to Mailpit - or which Mailpit can potentially change to help work around the problem.
@melloware commented on GitHub (Jul 6, 2024):
Thank you and thanks again for your wonderful work.
@melloware commented on GitHub (Jul 8, 2024):
@axllent we did a Youtube Podcast on Mailpit in Quarkus this morning thought you might be interested: https://www.youtube.com/watch?v=bJMoRPCzc14
@axllent commented on GitHub (Jul 9, 2024):
That's really awesome, thanks for the really positive feedback and for sharing the link with me @melloware! Very slick to see how you've integrated Mailpit into Quarkus...
Just for reference, the HTML check you were looking at in the video is documented here - basically it uses the "database" (a huge set of "rules" & supported platforms defined in JSON format) from caniemail.com to run those tests locally to see what elements / styles are problematic on various platforms / programs, and thus your overall score. You were getting 100% because your HTML was very simple and everything you had was supported, so it did not matter what you ticked or not, it was still 100% :) That will change drastically when you start to use CSS flex alignment, floats, background images, remote CSS, HTML5 etc....
@melloware commented on GitHub (Jul 9, 2024):
That is good to know!