Switching channels from top bar channel pulldown on search page doesn't work as expected

[lizmat]

The idea is that you should be able to repeat the same search on another channel by simply selecting the channel from the upper pulldown (apart from the using the channel pulldown in the search options, and clicking on Submit).

This currently doesn't work: it does instigate a new search, but on the channel that is selected in the pulldown.

The pulldown calls the submitSearchOnChannel(channel) JS function, which then tries to set the channel value in the form, and then submit that. But of course, we haz TWO of these forms, one for mobile, and one for other views.

What would be the best solution for this? I was thinking about calling submitSearchOnChannel(channel) with an extra type parameter (either 'Mobile' or 'Desktop'), generating the form with appropriately different ID's ('SearchChannelMobile' vs 'SearchChannelDesktop', etc.).

But this breaks down on the fact that there is only ONE upper channel pulldown. So that pulldown would need to know if it is in Mobile mode or not, to be able to call submitSearchOnChannel(channel) with the appropriate type info.

So I guess that boils down to wanting to be able to find out in JS whether we are in mobile mode or not. I don't seem to find a way, but am hoping that either @ogdenwebb or @Altai-man will be able to tell me quickly. Or think of another way of solving this. In any case, this solution would cause two less cases of duplicate ID's warnings in the validator :-)

[Altai-man]

The idea is that you should be able to repeat the same search on another channel by simply selecting the channel from the upper pulldown (apart from the using the channel pulldown in the search options, and clicking on Submit)

Doesn't it add a non-intuitive feature though? Not telling it shouldn't be this way, just as something to think about, I agree it's faster this way, but something tells me a very small chunk of users will actually discover it. Obvious is good.

I was thinking about calling submitSearchOnChannel(channel) with an extra type parameter (either 'Mobile' or 'Desktop'), generating the form with appropriately different ID's ('SearchChannelMobile' vs 'SearchChannelDesktop', etc.).

This is the way forward IMO. I mean, we do have a warning about this element ID being duplicated and we should eventually fix it. I even tried, but stumbled over the cro templates syntax.

So I guess that boils down to wanting to be able to find out in JS whether we are in mobile mode or not.

Maybe I misunderstand something, but just checking if the mobile one is visible or hidden won't work? If visible, take that, otherwise take another.

[lizmat]

Maybe I misunderstand something, but just checking if the mobile one is visible or hidden won't work? If visible, take that, otherwise take another.

Then my question is: how do I check that? :-)

[Altai-man]

Then my question is: how do I check that? :-)

Get the element by its unique ID and then people suggest this:

function isVisible(e) {
    return !!( e.offsetWidth || e.offsetHeight || e.getClientRects().length );
}

as we avoid jquery.

[lizmat]

But that would only work on things that are actually visible, right? So would be false for search options in a mobile view that isn't actually visible?

[Altai-man]

But that would only work on things that are actually visible, right? So would be false for search options in a mobile view that isn't actually visible?

It should be. And if it isn't so, then we need some other code to check for visibility.

[lizmat]

This has now been fixed.