Description: when i open .html file, it displays letters, symbols, numbers, etc., instead of content on 5.0, 5.1, 5.2, 5.3 alpha libreoffice viewer Steps to Reproduce: download and open EDB-35279-1.htmlhttps://opengrok.libreoffice.org/xref/core/sw/qa/core/data/html/pass/EDB-35279-1.html# Actual Results: displays letters, symbols, numbers instead of content Expected Results: display content fileopen test result: 5.0.0.0.alpha1+-ab465b9 garbage 5.1.0.0.alpha1+-1a6ec13 garbage 5.1.0.0.alpha1+-5b791ec garbage 5.2.0.0.alpha0+-f6a74ce garbage 5.3.0.0.alpha1+-4136757 garbage os: android 5.1 device: lyf flame 3 [ ls-4001 ] Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Android 5.1; Mobile; rv:57.0) Gecko/57.0 Firefox/57.0
Is this request still relevant? Supporting more file formats presumably also means that the size of the APK will increase (due to more services that will have to be included), so I tend to suggest focusing on those that are particularly relevant. In addition, the mechanism to open a file in Android Viewer currently depends on the Android system identifying the proper MIME type, which probably isn't the case for most of the proprietary and not so frequently used file types. (So supporting these might need some "open any file, ignore file type" handling instead (possibly hidden behind a setting?).)
Dear vihsa, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
(In reply to QA Administrators from comment #2) > Dear vihsa, > > This bug has been in NEEDINFO status with no change for at least > 6 months. Please provide the requested information as soon as > possible and mark the bug as UNCONFIRMED. Due to regular bug > tracker maintenance, if the bug is still in NEEDINFO status with > no change in 30 days the QA team will close the bug as INSUFFICIENTDATA > due to lack of needed information. > > For more information about our NEEDINFO policy please read the > wiki located here: > https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO > > If you have already provided the requested information, please > mark the bug as UNCONFIRMED so that the QA team knows that the > bug is ready to be confirmed. > > Thank you for helping us make LibreOffice even better for everyone! > > Warm Regards, > QA Team > > MassPing-NeedInfo-Ping I don't think this needs to be in needinfo. Implementation details probably can't be provided by the requester if they're not an LO developer. It's a fairly simple FR anyway, at least conceptually.
(In reply to third='beedell', first='roke', second='julian lockhart' from comment #3) > I don't think this needs to be in needinfo. Implementation details probably > can't be provided by the requester if they're not an LO developer. It's a > fairly simple FR anyway, at least conceptually. I agree that implementation details don't have to be provided by the requester. My question from comment 1 is primarily "Is this use case actually (still) relevant for you?", since there appears to have been a mass-filing for pretty much every file format that the desktop version of LibreOffice supports. Since supporting all of these on Android comes at a cost (needs time to be implemented, needs more space on the phone, maybe up to the point that some app store limits are exceeded,...), I'd like to know which of the formats are actually relevant in practice so those can be focused on. With that said, I just tested the scenario in this bug report (In reply to vihsa from comment #0) > Steps to Reproduce: > download and open > EDB-35279-1.htmlhttps://opengrok.libreoffice.org/xref/core/sw/qa/core/data/ > html/pass/EDB-35279-1.html# > > Actual Results: > displays letters, symbols, numbers instead of content > > Expected Results: > display content and opening that HTML file in Firefox or Chromium also just displays "garbage", and the file doesn't seem to actually be an HTML file: $ file /tmp/EDB-35279-1.html /tmp/EDB-35279-1.html: data $ file --mime-type /tmp/EDB-35279-1.html /tmp/EDB-35279-1.html: application/octet-stream So, from what I can see, this is actually NOTABUG, given the file itself is broken. If there's still a desire for HTML to be supported and that shouldn't work in general, I think that should be filed as a new report instead, so I'm closing this bug report as NOTABUG.