-
Notifications
You must be signed in to change notification settings - Fork 521
Feat: Add hover-activation hotspot / Extended hover area for navigation arrows (#658) #668
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
base: main
Are you sure you want to change the base?
Feat: Add hover-activation hotspot / Extended hover area for navigation arrows (#658) #668
Conversation
WalkthroughRestructures navigation button DOM to enlarge hover/click hotspots, tightens ImageViewer styling and max zoom, changes backend logging emit to write stdout lines prefixed with "[uvicorn]", and applies minor whitespace/formatting edits in several frontend files. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🔇 Additional comments (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
backend/app/logging/setup_logging.py (1)
231-250: Revert to using the configured logger instead of print.The
emitmethod now bypasses the entire logging infrastructure by usingInterceptHandlerand loses critical functionality:
- Log level filtering is ignored (always prints regardless of configured level)
- Custom color formatting from
ColorFormatteris bypassed- Consistent log formatting is lost
- The handler's configured formatter (line 278) is never used
Apply this diff to restore proper logging:
def emit(self, record: logging.LogRecord) -> None: """ Process a log record by forwarding it through our custom logger. Args: record: The log record to process """ # Get the appropriate module name module_name = record.name if "." in module_name: module_name = module_name.split(".")[-1] # Create a message that includes the original module in the format msg = record.getMessage() # Find the appropriate logger logger = get_logger(module_name) - # Log the message with our custom formatting - print(f"[uvicorn] {msg}") + # Log the message through our logging system with proper level and formatting + logger.log(record.levelno, msg)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
frontend/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (6)
backend/app/logging/setup_logging.py(1 hunks)frontend/index.html(1 hunks)frontend/src/components/Media/ImageCard.tsx(1 hunks)frontend/src/components/Media/ImageViewer.tsx(3 hunks)frontend/src/components/Media/NavigationButtons.tsx(1 hunks)frontend/src/pages/PersonImages/PersonImages.tsx(1 hunks)
🔇 Additional comments (3)
frontend/src/components/Media/ImageViewer.tsx (3)
39-39: LGTM: Reasonable zoom constraint.Reducing maxScale from 8 to 6 is a sensible constraint that prevents excessive zoom while still providing sufficient magnification for most use cases.
47-48: LGTM: Fixes viewer boundary issues.Setting
overflow: hiddenwithposition: relativeproperly constrains the viewer boundaries and prevents content from escaping the container.
74-75: Verify if the minimum size constraint is appropriate for all image types.Setting
minWidthandminHeightto70vminforces images to display at a minimum of 70% of the smaller viewport dimension (e.g., ~756px on a 1920×1080 screen). While this addresses the small-image display issue mentioned in the PR objectives, it may aggressively upscale legitimately small images such as icons, thumbnails, or small graphics, potentially degrading visual quality or causing layout issues.Consider testing with:
- Small icons or thumbnails (e.g., 100×100px images)
- Images with a large aspect ratio
- Various viewport sizes (mobile, tablet, desktop)
If issues arise, consider a more conservative value like
40vminor50vmin, or implement conditional sizing based on the original image dimensions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (3)
frontend/src/components/Media/NavigationButtons.tsx (3)
16-20: Add explicittype="button"attribute.While this button isn't in a form context, explicitly setting
type="button"is a recommended best practice to prevent unintended form submission behavior if this component is ever used within a form.Apply this diff:
<button className="group absolute left-0 top-0 z-20 h-full w-20 cursor-pointer bg-transparent hover:bg-transparent" onClick={onPrevious} aria-label="Previous image" + type="button" >
32-36: Add explicittype="button"attribute.Same recommendation as the left navigation button - explicitly set
type="button"as a best practice.Apply this diff:
<button className="group absolute right-0 top-0 z-20 h-full w-20 cursor-pointer bg-transparent hover:bg-transparent" onClick={onNext} aria-label="Next image" + type="button" >
21-25: Remove unnecessary styles for cleaner code.Minor code quality improvements:
- The
z-30on the inner divs is unnecessary since z-index only applies relative to siblings in the same stacking context (these are children of thez-20buttons)- The
hover:bg-transparentis redundant since the buttons already havebg-transparentas the base styleApply these diffs to both buttons:
<div - className="absolute top-1/2 left-4 z-30 flex -translate-y-1/2 transform + className="absolute top-1/2 left-4 flex -translate-y-1/2 transform items-center rounded-full bg-black/30 p-3 text-white backdrop-blur-md transition-all duration-200 group-hover:bg-white/40 group-hover:shadow-lg pointer-events-none"And update the button className:
- className="group absolute left-0 top-0 z-20 h-full w-20 cursor-pointer bg-transparent hover:bg-transparent" + className="group absolute left-0 top-0 z-20 h-full w-20 cursor-pointer bg-transparent"Apply similar changes to the right button.
Also applies to: 37-41
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
frontend/src/components/Media/NavigationButtons.tsx(1 hunks)
🔇 Additional comments (1)
frontend/src/components/Media/NavigationButtons.tsx (1)
16-29: I'm unable to access the repository due to cloning issues. However, I can analyze the review comment based on responsive design principles and the code snippet provided.Let me assess the concern raised:
Analysis of the hotspot behavior concern:
The review comment raises valid questions about the 80px (w-20 in Tailwind) hotspots:
Small mobile screens: On phones with viewports < 375px, 80px hotspots on each side would consume 160px, leaving only ~215px or less for content. This is a legitimate concern for older phones or landscape mode on smaller devices.
Very narrow viewports (<160px total): The overlap scenario is theoretical but technically possible in extreme cases, though highly unlikely in practice.
Lack of evidence: Without access to the codebase, I cannot verify:
- Whether responsive adjustments exist (e.g.,
sm:w-16ormd:w-20)- Whether container constraints are defined in ImageViewer
- Whether there are media query overrides
- What the actual implementation does to handle these cases
Conclusion:
The review comment raises a reasonable concern that should be verified within the actual codebase. Since I cannot access the repository to confirm whether responsive adjustments exist, the verification must be done manually.
Verify hotspot behavior on mobile and narrow viewports. The 5rem (80px) wide hotspots on each side may cause issues on small mobile screens and could reduce content visibility significantly. Confirm whether responsive adjustments exist (e.g., reduced widths on
sm:ormd:breakpoints) or if container constraints prevent layout issues on viewports narrower than 20rem.
This PR adds hover hotspots for the navigation arrows, extending the clickable area (~5rem) so users don't need pixel-perfect precision.
It also fixes the small-image display issue by setting a minimum width and height in the ImageViewer component.
Fixes #658
2025-11-28.01-51-55.online-video-cutter.com.mp4
Summary by CodeRabbit
Bug Fixes
Style
Chores
✏️ Tip: You can customize this high-level summary in your review settings.