Open gidrokolbaska opened 5 months ago
I am also experiencing the same issue; the touch area is misaligned. I initially thought it was a problem with version 0.2.0, but it also occurs in the latest version.
I have the exact same issue. Any solutions available?
Any solution for this?
If we can disable the ResponsiveScaledBox
for the widget that contains the WebView
it will fix it (At least for now)
Any idea how we can do it?
If we can disable the
ResponsiveScaledBox
for the widget that contains theWebView
it will fix it (At least for now) Any idea how we can do it?
I attempted two approaches without success:
1 - Wrapping a custom "Responsive" widget route by route
'/home': (context) => Responsive(child: const HomePage()),
This approach does not work because Dialogs cannot be accommodated, and if attempted, they expand to fill the entire screen. Additionally, it involves a lot of work with no guarantee that I won't forget something.
2 - Reversing the scale factor:
Transform.scale( scale: 450 / ResponsiveBreakpoints.of(context).screenWidth, child: WebViewWidget(controller: webController), ),
With this method, the taps are positioned correctly, but the website content extends beyond the screen boundaries. This approach is worth trying if the website itself is not heavily dependent on its width. Furthermore, in my scenario, I have only one breakpoint at 450, and I am unsure how to dynamically reverse the scale based on different screen widths.
Same problem here!
If we can disable the
ResponsiveScaledBox
for the widget that contains theWebView
it will fix it (At least for now) Any idea how we can do it?I attempted two approaches without success:
1 - Wrapping a custom "Responsive" widget route by route
'/home': (context) => Responsive(child: const HomePage()),
This approach does not work because Dialogs cannot be accommodated, and if attempted, they expand to fill the entire screen. Additionally, it involves a lot of work with no guarantee that I won't forget something.
2 - Reversing the scale factor:
Transform.scale( scale: 450 / ResponsiveBreakpoints.of(context).screenWidth, child: WebViewWidget(controller: webController), ),
With this method, the taps are positioned correctly, but the website content extends beyond the screen boundaries. This approach is worth trying if the website itself is not heavily dependent on its width. Furthermore, in my scenario, I have only one breakpoint at 450, and I am unsure how to dynamically reverse the scale based on different screen widths.
I tried wrapping the WebView widget with ResponsiveScaledBox
-> SizedBox
and the WebView
started to work fine and It works with dialogs too, I am still testing it with different screen sizes and understanding why this works
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
backgroundColor: Colors.blue,
title: const Text("Title"),
),
body: SizedBox(
height: ResponsiveBreakpoints.of(context).screenHeight,
child: ResponsiveScaledBox(
width: ResponsiveBreakpoints.of(context).screenWidth,
child: WebViewWidget(
controller: _controller,
),
),
),
);
}
Hi everyone, I'm catching up on the conversation.
I recommend using a ConditionalRouteWidget and selectively applying ResponsiveScaledBox for advanced usecases.
There are some screens where you don't want to scale. ResponsiveFramework v1 was rewritten to separate scaling and breakpoints. Now you can use them separate and control behavior per screen for greater flexibility.
Hi everyone, I'm catching up on the conversation.
I recommend using a ConditionalRouteWidget and selectively applying ResponsiveScaledBox for advanced usecases.
There are some screens where you don't want to scale. ResponsiveFramework v1 was rewritten to separate scaling and breakpoints. Now you can use them separate and control behavior per screen for greater flexibility.
it won't work in a scenario where you have a bottom navigation bar with x amount of tabs and one of the tab is a webview. You either wrap the whole screen which contains tabs and bottom navigation bar with ResponsiveScaledBox or don't wrap it at all. If you try to wrap only the tabs, they layout will break obviously.
If we can disable the
ResponsiveScaledBox
for the widget that contains theWebView
it will fix it (At least for now) Any idea how we can do it?I attempted two approaches without success: 1 - Wrapping a custom "Responsive" widget route by route
'/home': (context) => Responsive(child: const HomePage()),
This approach does not work because Dialogs cannot be accommodated, and if attempted, they expand to fill the entire screen. Additionally, it involves a lot of work with no guarantee that I won't forget something. 2 - Reversing the scale factor:Transform.scale( scale: 450 / ResponsiveBreakpoints.of(context).screenWidth, child: WebViewWidget(controller: webController), ),
With this method, the taps are positioned correctly, but the website content extends beyond the screen boundaries. This approach is worth trying if the website itself is not heavily dependent on its width. Furthermore, in my scenario, I have only one breakpoint at 450, and I am unsure how to dynamically reverse the scale based on different screen widths.I tried wrapping the WebView widget with
ResponsiveScaledBox
->SizedBox
and theWebView
started to work fine and It works with dialogs too, I am still testing it with different screen sizes and understanding why this works@override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( backgroundColor: Colors.blue, title: const Text("Title"), ), body: SizedBox( height: ResponsiveBreakpoints.of(context).screenHeight, child: ResponsiveScaledBox( width: ResponsiveBreakpoints.of(context).screenWidth, child: WebViewWidget( controller: _controller, ), ), ), ); }
This approach seems to work perfectly. It would be nice to hear if you tested further as you said you would @MostafaSolimanMO. In any case, thank you.
Hello, as the title states, when we are utilizing the ResponsiveScaledBox widget, the WebView is kind of misplaced which causes the inability to click anywhere properly on that webview on specific device sizes. What could be the cause?
Here is a video demonstration:
https://github.com/Codelessly/ResponsiveFramework/assets/54116985/5e09e289-6fd1-41cb-881c-cb4ba07bd277
Here is my ResponsiveScaledBox setup:![image](https://github.com/Codelessly/ResponsiveFramework/assets/54116985/361af699-e0fd-4a2c-bc37-b6e2331b7830)