[Resolved] Cleaning up Issues

[tneotia]

@erickok and @ryan-berger just went through the issues and here's a list of the ones I think can be closed... Just doing this to clean up a little, there's a lot of duplicates/issues already fixed & implemented. A lot are also regarding the old version of the library (pre 1.0.0 and 1.0.0 issues) which have been mostly resolved in the latest updates.

Again this is just in my mind, a lot could very well not be ready to close.

Should be good to close (total 63) (1 left):
#19 - seems we have implemented this?
#67 - should be possible now with style?
#125 - seems we have implemented this?
#166 - seems this is not an issue anymore?
#167 - seems this is not an issue anymore?
#172 - technically fixed because someone could implement this with customRender and cached_network_image
#195 - only OP and no other comments, hard to understand what the issue is
#199 - seems this is not an issue anymore?
#202 - seems this is not an issue anymore?
#203 - checked his HTML and it seems to be fixed in 1.0.0+
#210 - Is this still an issue?
#211 - I have used the widget in SliverList and didn't encounter this issue
#212 - Duplicate of #210 and seems to not be an issue.
#216 - Duplicate of #172 and also possible with customRender
#224 - seems this is not an issue anymore?
#229 - this is possible now by including the CSS in <style>
#230 - seems this is not an issue anymore?
#233 - PR fixing this is merged
#234 - can be fixed using customRender
#236 - duplicate of #29
#241 - fixed by #500
#243 - related to #169
#251 - seems this is not an issue anymore?
#254 - this is implemented now
#267 - is this fixed with @erickok s link rendering fixes?
#269 - too less information and video tags are working

#277 - incorrect CSS usage in HTML string

#287 - Tested his HTML on my Galaxy S8 (debug mode), my phone did not get stuck. There was some lag but I think this is more a quirk of debug mode trying to render all the CircularProgressIndicators than caused by the plugin. Once the images were loaded the scrolling was super smooth. Shouldn't be an issue.
#288 - doesn't seem to be an issue, just a question (and it was answered)
#289 - PR merged to fix issue in both this package and flutter itself
#294 - seems to be related to #289 which was fixed
#295 - seems to not be an issue anymore?
#300 - seems to not be an issue anymore?
#310 - congratulations post!
#313 - CircularProgressIndicator is now implemented to indicate image loading
#316 - we have support for this
#324 - being discussed in #323
#328 - fixed by #499
#330 - tested & fixed by new table rendering
#340 - fixed with new table rendering
#346 - tested and not an issue anymore
#352 - fixed by #392
#355 - not enough info and video does work
#356 - fixed by OP on his own
#360 - tested and not an issue anymore
#364 - video aspect ratio issues have been fixed
#367 - not enough info and justify is working for me
#375 - haven't encountered this at all, is this still an issue?
#376 - duplicate of #29
#380 - tested and not an issue anymore, duplicate of #360
#385 - duplicate of #153
#389 - tested and desired result is achieved. In order to put the gif in the center of the page I think the user will have to wrap the
Html in a SizedBox or something similar so the widget itself takes up the height of the screen.
#391 - is this still an issue? Doesn't seem very related to this package
#395 - tested, not an issue anymore
#397 - tested, fixed by #499
#403 - duplicate of #29
#411 - not enough information, but we do support inline styles
#426 - this was fixed, right?
#427 - duplicate of #308, related to #289 which was fixed
#454 - tested, seems to be fixed with @erickok 's link rendering fixes
#464 - fixed in recent PR, related to iframe attributes coming as null
#510 - resolved

Not yet but soon (total 13):
#130 - fixed with a custom image implementation
#153 - fixed with a custom image implementation
#159 - fixed when #522 is merged
#161 - fixed when #507 is merged
#168 - fixed when #522 is merged
#286 - fixed when #522 is merged

#301 - can be done using custom render but I'd still like to see more native support

#317 - could be closed when #522 is merged, maybe more is needed to fully address this?
#386 - can be done with a custom image implementation but we might want to have some first-party support
#448 - fixed with a custom image implementation
#478 - can be done with a custom image implementation
#487 - fixed when #509 is merged

Unsure (total 7):
#143 - Do we have this fixed?
#262 - Do we have this fixed?
#265 - seems to be a Flutter issue, is this fixed now?'

#270 - too less information, seems related to a specific option when rendering a scaffold?

#303 - no response from OP if the issue is still present, requires further testing maybe?

#337 - solution provided in comments, should we keep this open?

#433 - not enough information, should we keep this open?

Issues to keep an eye on (and potentially close later) (total 4)
#461 - awaiting response
#462 - awaiting response
#471 - awaiting response
#481 - awaiting response

Phew that was a lot to go through! Hopefully this can help keep the repo a little cleaner and make it easier to determine which issues to attack next.

[ryan-berger]

I'll take a look and start closing out some of those issues that for sure can be closed out.

We really ought to get a bot in here to clean things up and automate this out for us.... Are there any good actions to do so? I haven't really looked into it to much.

[tneotia]

A bot might only be good to close out issues that haven't had activity in x amount of time. Even that can be risky because there are issues from 2 years ago asking for features (and haven't had any more comments, just reactions)... I think for this huge batch of issues closing by hand will be better.
I plan to contribute a whole lot more to this package, so hopefully once the number of issues dips below 20/30 you can look into implementing a bot that does the above.

[erickok]

A bot can help but I agree, non-one likes their (totally valid) feature request or bug report being closed just because a bot finds inactivity. I'm sure there are bots that are smarter (maybe we label them as 'awaiting response' and the bot closes only those issues that are awaiting a response for a long time) but I have no experience with them.

[erickok]

Thanks for this work! I much agree I'd like to clean these up and will to so as soon as we can get some of those PRs merged. If you can, can you add reviews on those PRs without a review?

[tneotia]

Sure I will in a few.

There are a couple that I think we don't need to merge anymore because we now have the image render proposal finalized, so I'll indicate that when I get to those PRs.

[tneotia]

I don't have write access so all the PRs still say "review required" but I have added my review on all relevant PRs at this point.

[erickok]

Yes, no problem, I'll take care of it.

[erickok]

@tneotia I took the liberty of editing your original post to keep record of those tickets we still need to close/report/fix.

[tneotia]

Sure feel free. Thanks for doing this! Makes everyone's job a little easier :)

[erickok]

I think I closed all ticket where I deemed it appropriate. I might make another pass on the open tickets at some point. It's a lot of work! But for the moment we can either mark this as [Resolved] or would you prefer to leave it open as a reference?

[tneotia]

There are still a couple left in the list, but its very short. I would be comfortable with marking as resolved, now it'll be much easier to comb through the list of issues in the first place.

[tneotia]

Also @ryan-berger is there a way to allow people permission to create issue templates? I would like to come up with one so that we can standardize feature requests vs bug reports, and mandate HTML code to reproduce issues. Hopefully that can ensure something like this monstrosity doesn't pile up again. This could probably go hand in hand with a contribution guide, too.

[ryan-berger]

@tneotia The only way I could give you permission to do that would be via giving you full admin permissions. I could do that for a bit, but we should see if we can move this repo to a "team" repo so that we can customize permission levels

[tneotia]

No problem, I understand. If you're able to figure out custom permission levels let me know and I'd be glad to make issue templates and potentially a contribution guide!