Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix error in processor.js when using the vision_deficiency option #128

Merged
merged 2 commits into from
Aug 29, 2021

Conversation

julianwegkamp
Copy link
Contributor

Fixes the error in processor.js when using the vision_deficiency option as reported in issue #127.

Added a spec as you suggested, but I'm running into some strange behavior. On some test runs the mean_colour_statistics returns ["94", "71", "0"] (which I assume is correct) on other runs it returns ["240.506", "240.527", "242.569"]. This is likely the mean color from the page http://www.example.net/foo/bar. Do you recognize this inconsistency while running the specs?

1) Grover::Processor#convert when converting to an image when vision deficiency is set to `deuteranopia` is expected to eq ["94", "71", "0"]
  Failure/Error: it { expect(mean_colour_statistics(image)).to eq %w[94 71 0] }
  
    expected: ["94", "71", "0"]
        got: ["240.506", "240.527", "242.569"]
  
    (compared using ==)
  # ./spec/grover/processor_spec.rb:837:in `block (5 levels) in <top (required)>'

Copy link
Contributor

@abrom abrom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @julianwegkamp 👍

FYI I figured out the cause of the weird results you were seeing. It was caused by two different issues. First, it seems like the emulateVisionDeficiency method needs to be called after the content has been rendered. The documentation doesn't suggest this needs to be the case but I can say that it fails pretty reliably if it isn't afterward! Second, I had missed adding an await clause on that call meaning that it was applying the setting asynchronously. This would explain why it would sometimes work and other times not. On the occasions where it worked it was running after the content was rendered. The times when it didn't it appears to have actually broken the rendering mechanism completely. Those numbers coincide with what you see when the renderer doesn't capture the request and it actually goes out to the internet to fetch "example.com". i.e:

foo1

I noticed a few other places where I had not included the await clause so I've fixed them up too.

Thanks again

@abrom abrom merged commit 445ddc0 into Studiosity:main Aug 29, 2021
@abrom
Copy link
Contributor

abrom commented Aug 30, 2021

FYI released in v1.0.5

@julianwegkamp
Copy link
Contributor Author

Thx

@julianwegkamp julianwegkamp deleted the fix-vision-deficiency branch August 30, 2021 06:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants